►
From YouTube: Houston, We’ve Got a Problem! : How to Debug your Pipeline in... Vibhav Bobade & Vincent Demeester
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Houston, We’ve Got a Problem! : How to Debug your Pipeline in Tekton - Vibhav Bobade & Vincent Demeester, Red Hat
It’s always been nice to have CI/CD as a part of your infrastructure. Nothing better than being able to automate your workflows and have jobs done for you in a timely manner. It would be a shame if your jobs/pipelines break now would it. Now all you need to do is sit and take apart the individual components of your pipeline and figure out where you went wrong. We have all been there. Only if we could debug our Pipelines :) As common as task debugging is in the programming world, in the CI/CD world, it is ridden with complexities of the infrastructure and reiterative approaches which kill time. With Tekton, it is possible to debug your pipelines on the go without stopping/restarting your PipelineRun. Tekton is a Kubernetes based, lightweight, serverless, and an easy to manage CI/CD solution which a user can use to create as well as debug their PipelineRuns at a Step level to understand what is wrong with their pipeline providing a more complete CI/CD solution.
A
B
A
Right
so,
let's
go
through
the
agenda.
First,
we'll
define
a
little
bit.
What
do
we
mean
by
debug
in
debug?
What
then
we'll
go
rather
quickly
on
what
is
takedown
in
tekton?
In
a
nutshell,
hopefully,
you
know
already
a
bit
what
is
takedown
when
going
to
this
talk,
but
if
you
don't,
this
will
be
a
really
quick
introduction
to
tectum.
B
So
let's
talk
a
little
bit
about
about
debugging,
so
debugging
is
the
process
of
identifying
and
removing
errors
from
computer
hardware
and
software,
and
in
this
case
so
we
will
be
talking
about
debugging,
but
it
will
be
in
terms
of
pipelines
so
and
debugging
pipelines
themselves.
So
what
do
I
mean
by
when,
like
debugging
pipelines
and
what
are
pipelines.
A
A
Even
pipeline
there's
a
lot
of
type
of
pipeline
in
our
context.
In
the
context
of
this
talk,
we're
mainly
talking
about
cicd
pipelines
and
in
our
example,
is
more
accurately
be
useful
in
a
continuous
integration
pipeline,
but
yeah
we
will
focus
on
the
ci
cd
pipelines,
but
this
could
probably
apply
to
other
type
of
pipeline
that
can
be
done
inside
texan.
If
we
wanted
to.
B
Yeah,
so
why
would
we
ever
want
to
debug
our
pipelines
now
if
there
is
a
pipeline
which
works
on
your
machine,
but
not
on
the
ci?
It's
very
hard
to
understand
why
it's
not
working
on
the
ci,
because
you
would
need
to
understand
what
is
the
environment
the
pipeline
is
running
in
and
that
would
be
the
ci
environment
and
you
would
need
to
get
access
to
the
ci
environment
and
understand
this
thing.
B
So
debugging
pipelines
could
be
helpful
in
this
way,
where
you
just
get
access
to
the
ci
movement
and
figure
out
why
it's
not
working
on
the
ci.
But
then
there
are
also
times
when
it
only
runs
on
the
ci,
and
you
can't.
You
can't
run
it
on
your
machine
because
of
resource
constraints,
and
you
will
have
to
debug
your
pipeline.
B
A
B
B
You
get
really
frustrated
and
you
probably
want
to
leave
your
job
at
that
point,
but
you
can't
do
that
and
you
have
to
keep
debugging
pipelines
as
they
are,
but
there
are
better
ways
to
debug
pipelines
and
instead
of
doing
it
in
this
way,
and
some
ci
tools
allow
you
to
debug
pipelines
while
they're
running,
and
they
provide
a
great
support
for
this.
Some
of
these
examples
are
so-called
cr,
build
travels,
which
which
do
this
very
well
so
getting
inspiration
from
this.
A
Right,
so
how
how
how
would
you
debug
pipelines,
so
this
is
kind
of
explaining
what
we
will
do
in
tecton
and
what
other
tools
kind
of
do
in
some
matter,
so
debugging
pipeline?
What
do
you
want
for
for
it
to
do
one
once
one?
First,
you
want
to
be
able
to
pause
the
execution
of
your
pipeline
at
at
demand
so
anywhere.
If
the
user
wants
to
and
or
in
case
of
a
failure,
so
some
steps
or
some
action
failed.
A
A
What
processes
are
running
anything
really
that
could
help
them
debug
more
what
happened
and
why
it
failed
and
probably
also
re-execute
some
stuff
in
the
context
of
the
environment,
the
ci
environment
and,
of
course,
once
we
allow
the
user
to
drop
in
the
ci
environment,
we
want
to
allow
him
to
continue
or
break
the
flow.
So
if
he
feels
like
he
knows
what's
happening,
he
fix
it
manually
for
this
run
and
wants
to
see.
A
If
there's
one
anything
else
that
that
will
fail
later,
he
can
continue
it
with
success
and
let
the
pipeline
continue
running
or
if
he
knows
how
to
fix
it.
It's
pretty
sure
it's
it's
not
gonna
fail
after
he
can
just
go
and
fix
it,
and
thus
he
wants
just
to
not
consume
too
much
resources
and
break
the
flow
or
finish
the
pipeline
as
it
would
have
been
without
the
table
and
how
we
will
do
this
in
tecton.
We'll
dig
a
little
bit
more.
A
How
we
do
this
in
tecton,
but
this
is
based
on
tep,
the
number
42,
so
tp
stands
for
tickton
enhancement
proposal
and
this
tp
is
about
adding
breakpoint
on
fader
for
steps
inside
the
task
run.
This
is
focused
on
touchscreen
to
start
the
work,
but
this
tep
is
going
to
extend
more
and
more
as
as
we
go
so
first,
let's
go
quickly
on
what
is
takedown
for
those
who
are
who
do
do
not
know
what
is
takedown
or
have
a
really
general
idea
of
it.
A
A
This
is
governed
by
this
continuous
delivery
foundation.
The
ce
foundation,
which
is
a
kind
of
a
cousin
of
the
cncf
and
contributions,
are
coming
from
literally
everywhere
in
the
world
and
and
lots
of
companies.
Some
of
the
most
important
one
are
google
red
hat
cloud
b's,
ibm,
pivotal
and
d2iq.
There's
many
many
more.
A
A
A
A
B
A
A
One
example
that
we
have
upstream
is
there's
some
tasks
that
allows
you
to
create
a
mini
mac,
mini
vm.
I
don't
I
don't
even
know
if
it's
a
vm
or
not,
maybe
it's
a
real
one
somewhere
in
the
cloud
deploy
something
in
there
run
your
tests
get
back.
The
results,
as
everything
is
used,
is,
is
kind
of
running
into
containers.
You
can
do
this
and
it
provides
sets
or
it
aims
to
provide
a
set
of
powerful
user
interface
right
now.
We
do
have
a
command
line
tool,
an
official
command
line
tool.
A
A
B
So
there
are
a
few
concepts
in
tecton
that
really
helped
to
understand
how
the
tecton
pipeline
itself
works.
So
these
would
be
step
task,
pipeline
task,
run
and
pipeline
run,
and
we
couldn't
think
of
these
resources
in
two
different
of
two
different
kinds.
The
first
one
would
be.
The
definitions,
second,
would
be
executions
among
the
definitions.
B
You
can
just
define
these
tasks
and
pipelines
once
and
then
run
their
equivalent
run,
resources,
which
are
that
you
have
a
task
run
for
a
task
and
you
have
a
pipeline
run
for
a
pipeline.
So
if
you
want
to
run
a
task
with
certain
parameters,
you
would
basically
create
a
task
with
a
task
run,
and
when
you
create
this
task,
you
can
give
any
parameters
that
you
want
or
the
task
to
run
with.
If
there
are
some
of
the
parameters,
you
would
want
to
run
the
task
in
the
future.
B
You
can
do
that
as
well.
You
just
have
to
provide
different
parameters
in
that
case,
and
the
same
is
the
case
with
pipeline,
and
you
already
have
your
pipeline
with
the
tasks
which
can
run
either
in
sequence
or
in
parallel,
and
you
just
provide
a
pipeline
run
in
which
which
has
all
the
inputs
that
that
are
necessary
for
the
pipeline,
and
then
you
can.
B
If
you
have
a
certain
set
of
tasks
and
a
lot
of
these
tasks
are
present
in
the
task
catalog,
so
the
user
can
just
start
building
their
own
pipelines.
Okay.
So
let's
look
at
so.
Let's
look
at
what
a
pipeline
looks
like
here,
so
you
can
see
that
there's
a
pipeline
and
then
there
are
four
tasks
over
here
and
the
first
task
is
running
the
first
three
steps
and
each
of
these
steps
runs
in
a
container
of
itself.
B
Then
the
output
is
being
passed
to
the
next
two
tasks
which
are
running
in
parallel
and
the
second
task,
which
is
there,
is
sending
its
output
as
an
input
for
the
last
task,
which
is
there,
and
you
can
see
that
the
first
task
is
running
by
itself,
the
second
to
in
parallel
and
third
one
by
itself,
and
this
is
just
a
definition
of
the
pipeline
and
the
task
that
it's
references
or
has
defined
and
defined
in
the
pipeline
itself.
So
to
run
this
pipeline.
B
Actually,
you
have
to
provide
a
pipeline
run
and
which
sees
that
there's.
An
execution
of
the
pipeline
which
creates
task
runs
in
insert
to
create
each
of
these
tasks
are
task,
runs
and
execute
them,
and
before
there
were,
there
were
pipeline
resources
and
currently
they
are
being
deprecated
and
they
are
replaced
with.
B
B
B
So
let's
talk
about
what
a
task
actually
looks
like
okay,
so
here
in
the
task,
we've
got
a
spec
and
there
are
steps
which
we
can
define
in
the
task
and
we
are
going
to
focus
on
this
task.
Not
this
task
in
particular,
but
we're
going
to
focus
on
tasks
and
task
runs
and
trying
to
debug
them
in
the
future.
We
should
also
be
able
to
debug
pipelines.
B
A
A
A
This
is
what
we
mean
by
entry
point
and
the
talk
that
jason
and
christie
did
resumed
in
one
slide
is
we
do
overload
the
user
entry
point
so
either
the
screen
that
comes
from
the
image
or
the
one
that
the
user
provides.
We
override
overwrite
this
one
with
our
own
one.
We
control.
This
is
a
binary
called
entry
points,
so
we
what's
what
tekton
does
when
it's
schedules
a
pod
for
a
task?
It's
copying
itself
the
entry
point
inside
each
and
every
container
so
that
we
can.
A
B
A
Point
and
then
we'll
append
it
to
our
arguments.
If
the
user
provided
something
we
will
append
it
to
ours.
So,
for
example,
if
the
user
wanted
to
do
a
ls-l
as
entry
point
in
a
really
simple
way,
this
is
going
to
be
executed
as
our
entry
point
then
ls-l,
and
thus
we
can
control
whatever
it
gets
executed
and
that's
the
third.
The
third
step
is
gonna,
be
our
binary
is
waiting
for
some
signal
to
start.
We
are
using
files
from
previous.
A
Previous
steps,
if,
if
there's
any
previous
and
then
if
we
got
the
signal,
we
just
run
the
initial
command
that
the
user
provided
and
then,
when
it's
done,
we
can
gather
the
results
so
gather
if
it
failed
or
not,
which
exit
point
it
was
and
signal
the
next
step.
So
in
the
natural
normal
flow,
if
the
command
failed,
we
will
write
that
it's
an
error
and
the
next
step
entry
point
will
know
that
the
previous
step
failed
and
and
and
skip
and
and
and
so
on,
for
all
all
the
other
steps.
A
B
What's
the
issue
and
then
go
back
and
you
know
fix
the
issue
that
will
that
is
there
that
they
form
so
for
this,
what
we
do
is,
first
of
all,
we
mark
the
last
run
is
debuggable
by
adding
the
debug
spec
and
also
adding
where
we
want
the
breakpoint
to
be
on.
Failure
over
here
is
a
dynamic
break
point
which
basically
stops
the
step
stops
like
the
task
run
on
any
step
that
fails.
So
how
many
of
the
steps
fail?
B
The
step
would
be
paused
at
that
point,
and
the
user
can
basically
gain
access
to
the
environment
of
the
step.
At
that
point
and
what
what
is
done
is
when
the
user
gets
environment
access,
they
can
debug
do
whatever
they
want
over
there,
and
then
they
can,
after
that,
continue
the
step
from
there
by
marking
the
step,
either
as
a
success
or
a
failure
so
to
continue
and
break
the
breakpoint
and
mark
the
step
as
the
failure
we
provide
scripts
which
help
to
do
all
these
things.
B
B
Okay,
so
we
are
running
mini
cube
and
with
tekton
installed,
and
you
can
see
that
there
is
a
tecton
controller
and
that
book
pods
over
here
and
what
we
are
going
to
do
is
we
are
going
to
run
our
task
task
run,
which
contains
a
task
spec.
So
we
don't
have
to
create
a
different
task
and
this
is
going
to
have
a
task
which
is
going
to
write
a
file
and
then
start
it
and
then
read
the
file.
And
let's
see
how
that
goes.
So
this
and
somewhere
along
the
way.
B
B
So
I
don't
know,
what's
going
on
here,
let's
go
back
and
check
in
the
task
answer
like
what
happened.
Considering
like
we
are
on
on
failure
right
now.
We
can
see
this
debug
steps
saying
that
skipping
writing
on
writing
for
the
post
file
related
to
debug,
and
what
we'll
do
is
we
will
get
into
this
pod
and
go
to
the
step
start
container,
which
is
basically
step
dash
step
name,
that
is
the
container
name
format
for
this.
B
So
this
is
the
step
that
we
are
going
into
we're
going
to
see
like
what
is
going
on
we.
So
we
are
using
the
ubuntu
image
here.
So
there
is
the
bash
shell,
so
we
are
able
to
use
it.
So
we
are
in
the
bash
shell
in
the
container
right
now,
and
what
we
are
going
to
do
is
we
are
going
to
check,
cannot
start
share
data
new
right,
so
we're
gonna
going
to
check
if
new
right
is
there
or
not
just
in
case.
B
So
there
is
no
such
firewall
directory.
Let's
just
go
ahead
and
share
data
if
we
can
figure
this
out,
so
we
are
in
shared
data.
Oh,
it
seems
like
there
is
data
in
the
shell
data,
I'm
going
to
read
it.
Okay,
there
is
something
that
is
awesomeness
inside
now.
What
we're
going
to
do
is
we're
going
to
okay.
Now
we
know
that
the
data
is
in
data
file
and
not
in
new
write
file,
so
we
are
going
to
go
to
the
task
run
and
try
I'm
going
to
try
and
debug
it.
B
B
B
So
I'm
going
to
so
how
do
I
mark
this
as
a
success?
So
I'm
going
to
go
to
techton,
debug
scripts
and
in
the
scripts
we
have.
So
these
are
the
debug
scripts
which
come
along
with
the
debug
spec
and
the
user
can
use
to
either
mark
the
step
as
a
success
or
as
a
failure
and
close
the
breakpoint
at
the
same
time.
B
A
B
A
B
Let's
actually
see
how
that
works,
so
how
marking
your
failure
works
and
if
it
actually
marks
the
task
on
the
failure,
so
I'm
going
to
go
ahead
and
go
ahead
and
start
again
the
wrong
wrong
file
and
then
we'll
try
to
run
this
again
and
let's,
let's
mark
this
as
a
failure
and
see
how
it
goes.
So,
I'm
going
to
create
this
again
and
this
one
as
we
know
it
should
fail
on
the
second
step.
So,
let's.
B
Yeah,
so
we
have
this
fail
step
over
here
again,
so
we're
gonna
go
ahead
and
in
it
and
then
we
we
know,
we
know
the
drill
and
we
know
that
the
file
is
wrong
and
but
we
are
just
going
to
mark
the
step
as
a
failure,
so
we
are
going
to
run
the
script
for
failure.
So
debug
fail
continue,
so
I'm
gonna
run
this
and
even
if,
even
if
the
task
continued
and
we
had
the
output,
the
step
failed.
B
B
So
let's
recap
the
demo
and
let's
recap
the
demo
and
see
like
what
we
did.
Basically,
so
there
was
a
tasker
which
we
executed
and
a
step
in
the
task
run
failed.
So
we
had
already
provided
debug
breakpoint
on
failure
in
the
spec.
So
the
task
and
did
not
complete
the
execution,
rather
it
halted
so
that
the
user
can
come
in
for
debugging
and
when
the
task
was
halted,
the
user
could
get
access
to
the
debug
environment.
In
this
case.
B
That
is
a
step
container
and
the
user
could
figure
out
okay,
why
the
step
failed
and
then
mark
the
step
as
a
success
after
failure
after
after
it
failed.
So
they
can
just
let
the
task
and
continue
as
it
did
then
that
then,
after
figuring
it
out
the
task
and
continues
executing
with
no
problem
the
user.
Now
knows
the
reason
why
the
step
failed
in
the
first
place.
B
So
this
basically
didn't
involve
any
kind
of
you
know
hacky
processes
internally
it
did
it
did,
but
externally
did
not
let
the
user
to
figuring
figure
out
like
okay.
Why
did
this
fail?
I
probably
need
to
run
this
again.
The
user
had
to
run
the
task
run
just
once.
The
failure
happened
only
once
and
they
were
able
to
debug.
It
understand
the
root
cause
of
failure
and
then
go
ahead
with
running
the
task
and
again.
A
A
A
One
thing
that
we
would
like
to
provide
for
this
reason
and
for
other
useful
reason,
is
for
tecton
to
be
able
to
provide
its
own
shell,
probably
as
part
of
the
entry
point
itself,
either
the
same
binary
are
using
the
entry
point
injection
arc
to
inject
another
binary.
This
would
be
useful
because
then,
no
matter
what
image
is
used
inside
your
step,
you
could
debug
it,
but
it
would
also
mean
no
matter
what
no
matter,
what
image
you
use.
You
could
use
the
script
feature
of
of
tectum.
A
Then
we
also
want
to
support
more
modes
or
breakpoints
that
the
user
can
provide.
We
demodes
the
only
mode
that
is
currently
supported,
which
is
the
unfailure
mode.
We
would
like,
probably
to
add
more
things
like
debug
on
each
steps
or
specify
the
steps
that
we
want
to
debug
those
kind
of
things
we
need
to
support
and
probably
the
same
on
on
the
pipeline
itself,
so
be
able
to
say
I
want
these
and
these
stats
to
be
debuggable,
but
not
the
other
ones.
A
A
There's
some
end-to-end
test
that
runs
and
my
service
is
running
and
is
opening
a
port
to
debug.
I
would
be
able
to
would
like
to
be
able
to
hook
my
ide
on
this
running
process
somewhere
and
just
do
my
usual
id
debugging
feature
on
there
and
of
course,
one
of
probably
one
of
the
most
important
next
step
is
the
a
better
user
experience.
A
Of
course,
we
are
open
to
any
feedback
on
on
this,
because
it's
not
set
in
stone,
it's
gonna,
be
an
experimental
feature
to
start
with
so
yeah.
We
would
like
to
hear
from
you
and
yeah
thank
you
for
for
attending
this
talk
as
other
beautiful
talk.
We
are
available
on
chat
for
questions
so
yeah.
Thank
you
for
for
listening
to
us
and
watching
this
talk.