►
Description
In this call we discussed the common use cases from the issue which is one of the most popular/discussed issues within Verify.
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/15603
The actions from this meeting are to split the issue into a cancel and timeout case. The timeout case is harder because of the case of losing connectivity to the runner makes running a script on it practically impossible. We may find more timeout cases we can support but for now are focused on the user cancelation case and documenting alternatives for the timeout case that maybe possible through the webhook.
Meeting notes (internal link): https://docs.google.com/document/d/1oYp0Fi9PPAlFvMxpEJ0eoLXIz7LcspvDtci6zRmEIjs/edit?usp=sharing
A
A
Let's
talk
about
the
actual
problems
that
customers
are
having,
as
opposed
to
starting
with
the
solution,
so
I
pulled
out,
I
reviewed
the
issue
and
looked
through
all
of
the
comment
that
contained
use
case
or
problem
or
some
summary
of
what
a
customer
was
running
into.
It
really
pulled
out
two
big
themes
of
this:
the
person
that
resources
gets
started
by
the
pipeline
and
they're
like
running
when
the
pipeline
is
canceled
or
timeouts
times
out.
A
I
guess
the
right
word
and
the
other
is
that
there
are
things
that
customers
want
to
do
every
single
time
a
pipeline
run
whether
it
is
susceptible,
is
canceled
or
times
out
and
with
the
bug
that
we're
having
today.
Neither
of
those
things
can
happen.
So
there's
some
comments
in
there.
If
there's
a
disagreement
or
additional
contact
that
I
can
provide
from
those
would
be
great.
B
A
Fair
I
think
we've
been
down,
though
we
don't
know
how
to
fix
the
path
quite
a
few
times.
That's
why
we
wanted
to
surface
back
up
and
say
instead
of
trying
to
fix
the
thing
as
described.
Are
there
alternative
to
solving
the
problems
here,
and
maybe
that's
what
we
end
up
with?
Is
here's
an
alternative
way
to
help
with
these
problems,
and
these
themes
of
resources
start
and
I
can't
stop
them,
so
they
run
forever.
So
I
have
to
do
manually
or
hey
a
pipeline
is
running
I
always
want
to
go.
Do
a
thing!
D
A
Let's
have
a
bit
of
a
segue
into
the
second
bit
that
I
wanted
to
get
to
a
constraint
on
the
solution
that
maybe
we
can
Implement
and
talk
about
fighting
off
a
smaller
chunk,
but
I
want
to
make
sure
that
are.
Are
we
committed
to
solving
these
problems
here?
We
only
want
to
solve
for
one
of
these
and
say
this
is
the
thing
we
want
to
attack.
First,
it
looks
like
there
were
more
comments
about
resources.
A
Starting
then
I
always
want
to
do
a
thing
always
doing
a
thing
could
be
making
sure
that
I
shut
down
all
the
environments
and
clean
up.
You
know
all
the
things
in
my
kubernetes
cluster
or
whatever
it
might
be,
but
it
is
there
one
of
these
that
we
should
focus
on
Instead
at
the
core
of
the
problem,
and
that
might
help
us.
You
know
with
the
solution
space.
D
D
A
D
I
think
we
need
to
I
think
we
need
to
constrain
down
from
there
like
cancellation,
okay,
like
there's
only
so
many
triggers
for
cancellation
timeout
for
whatever
or,
for
example,
is
a
different
thing
or
or
job
failure
is
a
different
thing
or
foreign
's.
A
huge
problem,
because,
because
part
of
the
timeout
might
because
of
some
kind
of
networking
issue
and
like
we've
lost
contact
with
where
the
jobs
are.
C
D
Like
I,
don't
even
know
if
it's
solvable
at
all,
and
so
if
we
can
avoid
that
I
think
cancellation
is
like
a
user-defined
action
like
that
actions
come
from
a
user.
We
know
what's
happened,
presumably
we're
still
in
contact
with
things
nothing's,
timed
out
or
whatever,
and
so
I
think
I
think
that's
a
much
more
a.
A
So
I
I
think
there's
an
assumption
there
that
the
thing
that
we
need
to
go
cancel
is
a
runner.
What,
if
it's
just
some
other
thing
in
my
kubernetes
cluster,
though
like
I've
got
tests,
Hardware
I've
got
to
go
set
up
and
I
I
start
that
in
my
job,
I
set
up
an
environment
I'm
still
connected
to
that,
but
the
job
that's
running
on
the
runner
time
now.
A
So
maybe
we
constrained
this
on
hey,
you
still
have
connectivity
to
the
things
you
want
to
stop.
If
that
connection
is
timed
out,
we
can't
solve
for
that
problem,
but
if
the
job
is
timed
out,
we
can
anything
that
you've
already
started
and
don't
have
connectivity
to.
We
can
try
to
set
a
calculator
instead
of
shut
down
to
that
or
run
the
script.
That
would
do
that,
for
yourself.
A
B
I
think
I
think
ensuring
the
after
script
runs,
and
then
you
know
like
properly
shutting
down
any
services
or
whatever
you
started.
I
think
they're
two
separate
times
and
maybe
one
can
be
addressed
by
the
other,
maybe
making
sure
that
the
after
script
runs
is
a
way
to
like
it's
kind
of
a
roundabout
way
to
make
sure
the
other
one
happens
or
it.
You
know
you
could
Implement.
You
could
Implement
shutting
down
your
services
in
your
after
script
if
it
was
guaranteed
to
run,
but
I
think
there
are
two
problems:
yeah.
A
So
I
I
the
use
case
of
wanting
to
run
the
after
script
I
think
was
that
I
used
the
after
script
to
go,
shut
down.
Whatever
is
happening
in
my
kubernetes
collector
and
they
might
have
a
big
hammer
that
does
that
or
it
might
just
be
yeah.
It
might
send
a
slack
message.
You
could
have
like
hey
this
kubernetes
clusters,
but
there's
notes
are
still
running.
Somebody
should
go.
Look
at
that
thing
like.
A
A
Okay,
so
if
we
further
so,
let's
kind
of
pivot
into
further
constraints
on
the
solution
set
Elliot,
you
talked
about
time.
Health
we've
been
discussing
that
for
a
bit
and
we
still
do.
We
think
we
can
solve
for
that
use
case.
The
runner
is
typed
out
pipeline
gets
into
a
state
where
we've
hit
that
threshold
for
pipeline
timeout
or
job
timeout,
and
then
an
after
script
should
run.
Do
we
think
that
we
can
solve
for
that,
or
is
that
timeout
busyness
still
too
hard.
B
I
mean
I
in
my
mind,
part
of
the
problem
is
that
there
are
many
places
where
timelines
can
happen.
Yeah
like
places
that
come
to
mind,
because
it's
recent
is
like
the
pipeline
itself,
could
time
out
or
there's
a
timeout
when
you
run
a
go
test,
there's
a
default
timeout
of
I
think
10
minutes
the
time
I
could
happen
there
and
I
think
the
pipeline
would
see
that
as
the
job
having
failed,
yeah
and
then
and
then,
like
Elliot,
said
there
could
be
like
Network
timeouts.
E
D
Of
getting
this
is,
this
is
something
we
need
to
tease
apart.
It's
like.
Are
we
trying
to
use
this
as
a
rescue
for
when
our
system
or
infrastructure
is
failing,
or
are
we
trying
to
just
do
some
insured
cleanup
on
a
user-defined
action?
You
know
whatever
it
is
tearing
down
some
infrastructure
or
releasing
a
resource
and
I
think
in
in
that
second
case,
we'll
say:
releasing
a
resource.
It's
like
a
planned
thing
like
it's
a
thing.
D
B
B
E
C
D
C
That
would
give
them
the
option
to
run
a
different
pipeline
on
cancel,
which
is
one
of
the
things
that
some
of
the
use
cases
wanted.
So
I'm
also
wondering
to
build
on
that
is
like.
Can
we
build
two
solutions
like
like
to
handle
the
different
use
cases
right
like
we
want
to
run
after
script,
because
it
seems
like
it
should
run
on
cancel,
but
also
have
a
web
hook
so
that
we
can
for
the
people
that
want
to
do
the
thing
that
this
doesn't
handle,
that
they
can
do
other
things
or
like
like?
Is
that?
D
E
C
No,
you
have
to
I
mean
it
will
you
can
send
it
to
a
pipeline
or
to
the
pipeline,
but
it
will
just
like
run
the
pipeline,
so
you
have
to
like
then
configure
your
pipeline
to
make
it
go
to
the
right
place,
which
is
more
complicated.
It
would
be
nice
if
the
the
web
hooks
were
more
granular
like
you
could
find.
E
A
B
D
You
point
it
somewhere
and
then
you
run
a
pipeline
that
then
has
to
like
process
the
web
hook
payload
to
decide
if
it
needs
to
do
the
thing.
If
it
needs
to
go
to
Queen
up,
it's
going
to
be
doing
the
processing
all
the
time
and
most
of
the
time
it's
not
going
to
need
to
do
it
right
if
I'm
doing
only
on
cancellation
so
for
every
job
that
gets
for
every
job
that
changes
state,
then
this
Web
book
is
going
to
go,
get
fired
off
so
I
would
like.
D
A
C
A
A
A
So
that
might
be
an
outcome
here.
Is
that
we
document,
if
you
want
to
ensure
that
resources
or
you
know,
environments,
started,
get
cleaned
up.
You
may
look
at
the
web
hook
and
look
for
jobs
that
are
supposed
to
do
it
and
if
they
fail
then
go
do
it
yourself.
That
could
be
an
a
like
Hedgehog
kind
of
a
hey
things
failed
within
our
infrastructure.
This
is
the
way
that
we
recommend
you
go
clean
it
up
and
that's
an
okay
outcome,
I
think.
A
A
So
that
being
said,
if
we
split
this
apart,
this
issue
is
done
and
say:
hey
really.
What
we
want
to
focus
on.
First,
is
a
user
cancel
a
job
or
a
pipeline?
We
ensure
that
Aftershock
always
runs,
and
then
the
other
is
that
the
pipeline
typed
out.
We
ensure
that
after
script
always
runs,
are
there
lockers
to
those
things
and
what
would
be
the
next
step
to
uncovering
those
and
getting
them
unblocked
foreign.
A
Which
we've
had
a
couple
there's
a
proof
of
Concepts
that
we're
on
our
team
worked
on
already
that
Tian
I
think
is
reviewing
right
now,
so
maybe
that's
that
will
help
uncover
for
each
of
those
use
cases
what
the
exact
blockers
are,
and
maybe
we
just
move
on
to
one:
that's
not
blocked
first,
regardless
of
the
impact
or
reach
of
that
solution.
Just
it
gets
movement
here
and
better
understand
or
a
perceived
region
of
impact
understanding,
so
yeah
I.
A
Think
next
steps,
then,
would
be
completely
issue
break
out
the
cancellation
into
a
new
issue
revamp
this
one
as
a
timeout
focused
and
have
Tian
after
the
review
of
the
proof
of
concept
and
reviewing
the
notes
here
way
in
with
which
of
those
use
cases
that
POC
could
solve
for
or
as
close
to
the
following
four
and
we
get
that
issue
scheduled
I.
Think
I'd
like
to
better
understand
to
Circle
back
a
little
bit
on
constraints.
Talk
about.
Should
we
constrain
this
to
hey
this?
A
B
D
D
E
D
A
So
the
documentation
calls
out
it
happens
in
a
new
shell,
but
it
should
be
part
of
that
same
job.
We
could
change
that
Paradigm
and
say:
hey,
let's
get
spun
up
on
its
own
Runner.
Anything
that
you
need
that
new
Runner
to
know
about
make
sure
is,
in
you
know
some
sort
of
global
variable
dot
environment
file
whatever
it
might
be,
so
that
you
can
actively
assume
nothing
exists
after
that
job
and
kind
of
timed
out
or
canceled,
and
that
the
scripture
know
about
it.
B
E
C
C
D
A
D
A
Be
pretty
cool?
That's
almost
like
that.
Workflow
work,
that's
happening
of
State
changes
within
a
job,
in
addition
to
firing,
webhook
also
go.
Do
this
thing
outside
of
the
pipeline:
yeah,
yeah,
okay,
so
just
backing
up
a
little
bit.
What
I'm
hearing
from
straight
away,
because
as
we're
getting
close
to
time
is,
if
that
Runner
headed
up,
we
can't
connect
to
it
running
an
after
script
on.
A
E
E
D
Know
about
it
right
away
the
way
the
runner
gets.
That
message
is
every
I,
don't
know
a
couple
seconds
or
whatever
it
is
when
it
sends
a
partial
chunk
of
the
logs
from
the
job.
If
a
cancellation
has
occurred,
it
go,
it
gets
put
in
the
response
to
that
job.
Log,
update
and
so
it'll
send
some
logs
and
then
look
at
the
response.
D
A
I
would
say
so:
let's
create
that
as
I'll
create
that
as
a
new
issue
or
find
an
issue
with
it
better
calls
out
the
use
case.
That
will
be
the
one
that
we
focused
on
first
I.
Think.
Secondarily,
we
should
work
on
some
documentation
that
recommends
hey.
You
can
use
the
web
hook
to
go,
do
any
sort
of
cleanup
on
test
boxes
or
whatever
that
you
have
set
up,
that
after
you're
trying
to
use
after
script
to
cancel
or
shut
down
gratefully.
E
A
I
think
there's
some
giant
caveats
there
of
you've
got
to
document
as
you
go.
Here's
all
the
things
that
I've
done
so
that
they
could
be
in
either
a
the
webhook
payload
or
be
sitting
somewhere
else
externally
that
that
script
can
grab,
because
if
we
lose
connection
to
the
runner,
we
can't
get
that
stuff
out
of
the
runner
like
that's
that's
the
hard
part
here
right
is
that
if
the
runner
goes
down
or
for
some
reason,
Network
timeout
meteor,
whatever
like
assume
nothing
about
or
assume
you
can
get
nothing
off
of
the
runner.
A
E
D
A
A
All
right,
cool
I'll
write
this
down
in
the
notes
and
execute
on
those
next
steps
and
I'll
upload
this
to
unfiltered,
probably
at
the
private
video
just
for
now,
but
if
folks
think
that
it
should
be
public
great
and
we'll
make
it
such
all
right,
thanks
thanks
everyone.
Thank
you
appreciate
it.
Bye-Bye
thanks.