►
From YouTube: Houston, We’ve Got a Problem! How to Debug your Pipeline in Tek... Vibhav Bobade & Vincent Demeester
Description
Houston, We’ve Got a Problem! How to Debug your Pipeline in Tekton (in realtime) - 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. We have all been there. Only if we could debug our Pipelines in realtime :) 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.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
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'll
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?
B
A
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
you
can't
run
it
on
your
machine
because
of
resource
constraints,
and
you
will
have
to
debug
your
pipeline.
B
A
B
A
Right,
so
how
how
how
would
you
debug
pipeline?
So
this
is
kind
of
explaining
what
we
will
do
in
tecton
and
what
other
tools
kind
of
do
in
some
manner
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
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
and
finish
the
pipeline
as
it
would
have
been
without
the
table
and
how
we
will
do
this
in
tecton
will
dig
a
little
bit
more
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.
A
This
is
focused
on
touch
run
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
not
know
what
is
takedown
or
have
a
really
general
idea
of
it.
If
you
do
know
takedown
very
well,
the
next
few
minutes
will
probably
be
a
little
bit
boring,
but
it's
okay.
A
So
what
is
checked
on
in
a
nutshell,
tecton
is
an
open
source
project
that
aims
to
provide
a
set
of
standards
and
share
and
shareable
components
for
building
a
kubernetes
society
ci
cd
system.
This
is
governed
by
this
continuous
delivery
foundation.
The
ce
foundation,
which
is
a
kind
of
a
cuisine
of
the
cncf
and
contribution,
are
coming
from
literally
everywhere
in
the
world
and
and
lots
of
companies.
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
Com
can
be
made
of
different
tasks
together,
and
these
can
be
pre-existing
tasks,
new
tasks
that
you
can
create
right
in
the
pipeline
itself,
and
then
you
can
just
basically
compose
different
tasks
together
to
form
a
pipeline,
and
this
really
shows
the
composability
of
tecton
itself
when
it
comes
to
creating
pipeline
and
to
run
each
of
these
stars
and
pipeline
to
have
these
as
reproducible
as
possible.
You
can
just
define
these
tasks
and
pipelines
once
and
then
run
the
equivalent
run.
B
Resources
which
are
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
other
parameters,
you
would
want
to
run
the
task
in
the
future.
You
can
do
that
as
well.
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
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're
using
files
from
previous.
A
Previous
steps,
if
if
there
is
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
the
other
steps.
A
B
This
entry
point
hack
and
a
little
bit
flip
it
over
its
head
and
use
this
hack
to
actually
control
the
life
cycle
of
the
steps
itself,
so
that
when
a
step
is
executing
and
it
fails,
the
step
should
stop
at
the
failure
and
not
stop
the
execution
of
the
task
run
itself
and
the
user
should
be
able
to
go
into
the
environment
and
then
debug
it
and
troubleshoot
and
figure
out.
What's
the
issue
and
then
go
back
and
you
know
fix
the
issue
that
will
that
is
there
that
they
found
so
for
this.
B
So
what
we
do
is,
first
of
all,
we
mark
the
last
one
is
debuggable
by
adding
the
debug
spec
and
also
adding
where
we
want.
The
break
point
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
in
that
book
pods
over
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
and
itself
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.
So
this
is
the
step
that
we
are
going
into.
B
We
are
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,
so
there
is
no
such
file
directory.
B
A
B
B
Script
bash
in
the
step,
script
bash,
so
the
second
step,
so
the
right
or
seem
to
work
well
and
the
stat
is
doing
a
start
on
share
data
new
right,
which
is
wrong
because
it
seems
like
it's
writing
to
data
and
not
you
right.
So
I'm
going
to
go
ahead
and
fix
this
right
away
and
then
considering
that
considering
that
at
the
end
in
the
last
we
are
eating
shared
data
data,
so
I
think
it
should
work.
So
we
just
mark
the
step
as
a
success
for
now.
B
So
let's
go
back
to
the
container
and
then
mark
this
task
run
as
a
success.
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
B
A
B
A
B
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
in
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
tactile.
A
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.