►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Mario’s Adventures in Tekton Land - Vincent Demeester, Red Hat & Andrea Frittoli, IBM
Tekton is a Kubernetes-native, lightweight, easy to manage CI/CD pipelines engine. Pipeline building blocks can be reused, version controlled and curated in a catalogue that embeds best practices. Tekton, hosted by the CD Foundation, aspires to be the common denominator in CI/CD. The Tekton team wanted to make sure that the project is going in the right direction by "dogfooding" i.e. by using Tekton to run its own automation "plumbing". The initial continuous integration setup embedded most of the testing pipelines in bash scripts. The speakers replaced this with Tekton, hence improving the readability of the pipelines and the reproducibility of CI runs. Eventually, they moved onto continuously delivering Tekton and its pipelines via Tekton. In this talk, the speakers will tell their experiences about using a cloud-native pipeline system to test, release and continuously deploy itself.
https://sched.co/UabG
A
So
we're
gonna
talk
about
that
footing
and
we
decided
to
use
the
Mario
theme
because
our
dogfooding
project
is
called
plumbing
and
what
Myo
does
is
plumbing,
so
the
agenda
will
go
quickly
on
what
is
Tecton.
Hopefully,
people
know
a
little
bit
about
Tecton,
or
at
least
a
little
bit
above
about
our
kubernetes
work,
because
otherwise
it's
gonna
be
a
little
bit
hard
to
follow.
A
I
think
then
we're
gonna
talk
about
our
plumbing,
how
we
fix
things
that
we
discover
what
was
not
working
and
where
we
are
where
we
are
right
now
and
what
we
need
to
do
to
actually
have
something
that
that
Tecton
will
take
down
just
by
itself.
So
first,
what
is
Tecton
tectonics
sets
of
project
sets
of
components
to
provide
a
set
of
share
and
standout
components
to
build
ICT
system
on
top
of
Cuba
notice,
there's
a
bunch
of
projects
and
we
discover
our
needs
while
doing
it.
A
It's
governed
by
the
continuous
delivery
foundation
and
contribution
are
coming
from
Google
who
created
the
project
right
at
cloud
is
IBM,
pivotal
Salesforce,
like
there's
a
lot
of
interest
and
a
lot
of
contributors
and
I.
Think
now
we
are
over
100
contributors
or
something
like
this
Tecton
in
a
nutshell,
so
we
are
extending
Q&S
API
using
series.
So
hopefully,
who
knows
what
series
is?
A
A
Everything
runs
into
containers,
so
your
jobs,
your
like
anything,
you
will
run
as
part
of
your
pipeline-
will
run
into
a
container.
So
this
is
something
you
have
to
keep
in
mind.
While
writing
writing
pipelines,
and
even
Tecton
yourself
runs
into
a
container
you
can
deploy
on
any
platform.
Obviously
you
can
deploy
on
communities
because
it
runs
in
communities
but
you're
not
limited
to
deploying
on
communities.
You
can
deploy
on
anything
that
can
have
a
binary
in
a
container
and
targeting
something,
and
we
provide
a
cool
CLI
that
we
are
hoping.
B
Few
concepts
are
introduced
with
Tecton
the
core
one
is
a
step
which
is
basically
a
command
which
is
executed
in
a
container,
so
it
has
access
to
usual
things
like
volumes,
environment,
variables,
config
maps,
etc.
So
this
is
the
first
constituent
racing
in
Tecton.
Then
we
have
the
task.
The
task
is
a
CD,
so
it's
a
new
resource
for
kubernetes,
which
is
a
list
of
sequentially
executed
steps.
So
these
are
all
containers
that
will
be
executed,
one
after
the
other
within
a
pod
and
kubernetes
and
the
pipeline,
which
is
a
graph
of
tasks.
B
So
we
can
have
tasks
running
in
parallel
or
sequentially.
It
all
depends
how
you
define
dependencies
between
the
tasks
in
terms
of
resources-
and
this
is
the
next
CD
that
we
define
its
pipeline
resources,
which
is
an
abstraction
on
top
of
a
common
type
of
resources
that
you
may
want
to
use
in
your
pipelines
like
a
git
repository
or
a
docker
image,
or
even
like
a
kubernetes
cluster.
Let's
say
you
want
to
deploy
a
kubernetes
cluster.
You
need
credentials.
So
that's
your
resource
for
that.
B
All
these
tasks
pipeline
resources
allow
you
to
define
the
static
structure.
If
you
will
of
your
pipeline,
but
to
execute
it
to
actually
run
it,
you
need
extra
resources.
The
pipeline
run
is
what
you
need
to
trigger
a
pipeline.
If
you're
working
with
tasks,
you
can
use
a
task
run
to
trigger
a
task,
a
task
correctly.
Otherwise,
when
you
trigger
a
pipeline
using
a
pipeline
run,
all
the
correspondent
task
will
be
tasks
run
will
be
created
for
you,
and
this
is
just
a
visualization
of
what
I
just
talked
about.
B
So
the
green
boxes
are
the
tasks,
and
then
you
see
the
steps
within
and
the
IND
arrow
represents
inputs
and
outputs,
and
you
can
associate
tasks
in
this
way
using
outputs
so,
for
instance,
the
first
green
box
as
an
output
which
is
used
as
an
input
to
the
following
task.
That
means
that
this
went
the
daj,
so
the
graph
of
the
pipeline
is
built.
It
will
make
sure
that
the
first,
the
second
and
the
third
tasks
are
not
executed
until
the
first
one
is
complete.
B
Yeah,
as
Winston
said,
Tecton
is
not
just
five
points
of
pipeline
is
the
core
component,
but
along
the
way
we
introduce
more
and
more
project.
The
catalog
is
shareable
tasks
finishing,
so
we
want
to
have
tasks
if
everyone
can
reuse
and
they
embody
best
practices.
So,
for
instance,
if
you're
developing
Ingo,
you
can
have
a
task
that
you
use
to
build
your
goal
code
or
to
run
the
linker
on
top
of
it
or
run
unit
tests.
This
is
a
solved
problem.
B
It's
embedded
into
a
task,
so
there's
no
need
for
everyone
to
go
and
rewrite
it
again
and
again
again,
the
CL
I
will
show
it
later
is
cool
CLI
to
control
your
pipeline
and
tasks.
Triggers
is
a
project
that
allows
you
to
define
to
define
a
way
that
you
can
trigger
your
pipeline
runs
instead
of
triggering
them
manually.
A
Right
so,
let's
dig
into
the
actual
plumbing
that
we
did
so
first,
we
need
to
define
what
we
mean
by
plumbing
I.
Think
it's
the
same
for
everybody,
but
the
definition
is
that
the
system
of
pipes
stands
fitting
and
anything
needed
to
run
water
supply,
eating
and
sanitation
in
the
building
for
us
for
I.
Here
it
means
continuous
integration
really
set
up
test
infrastructure,
any
scripts
that
we
would
need
to
run
our
thing
any
thing
that
helps
us
manage
our
projects
in
a
lab
or
in
maybe
even
in
slack.
A
So
this
is
why
we
call
the
project
plumbing.
So
our
initial
plumbing
and
Tecton
was
coming
from
Canada,
because
historically
Tecton
pipeline
Tecton
city
pipeline
is
coming
from
creative.
It
was
spin
up
of
kinetic
build
and
so
it
this
means
it
runs
only
on
Google
Cloud.
It
makes
an
every
usage
of
pro
and
we
initially
shared
scripts
containers,
images
and
literally
everything
with
Kennedy.
So
once
we
got
out
of
the
Kennedy's
organization,
we
needed
to
do
things
our
own
way.
C
B
B
It's
the
micro
service
that
are
responsible
for
the
life
cycle
of
a
CI
job
that
provides
a
dashboard
where
you
can
see.
What's
going
on.
Tide
is
a
component
that
manages
merging
made
into
into
your
repository,
which
is
not
easy
job
to
do,
because,
yes,
you
may
have
many
commits
and
try
to
merge
at
the
same
time,
and
if
you're,
not
careful,
you're
breaking
yourself,
horologium
is
used
for
Crone
type
of
triggers
and
sinker
as
basically
doing
garbage
collection.
A
A
And
the
first
thing
was:
let's
own
our
scripts,
so
the
first
step
towards
independence
of
from
Canada
was:
let's
create
the
plumbing
repo.
Let's
document
how
it
works,
let's
create
our
own
scripts
so
that
we
can
maintain
and
we
don't
depend
on
what
skinny-dip
does
and
let's
also
build
our
own
CI
image
so
that
when
we
and
when
we
update
or
when
Kennedy
that
dates
its
image
to
add
a
new
components,
if
we
don't
need
it,
we
don't
really
need
it
in
our
image.
A
Sorry
I,
don't
think
I
think
my
mic
is
really
doing
anyway,
and
the
second
step
was
trying
to
do
release
with
Tecton
using
Tecton.
So
the
goal
was
I.
Think
we
managed
to
do
that
in
the
zoo
that
read
at
zero
reserve
Tecton.
So,
let's
the
goal
was
to
be
able
to
see
if
the
version
of
Tecton
we
were
using
was
actually
usable
to
build
our
own
tool,
because
if
it's
not
usable
for
us
to
use,
it
doesn't
make
sense
to
to
market
to
others.
A
So
we
actually
find
some
some
tasks
to
build
tests
and
indigo
code
to
publish
images
and
to
generate
the
release.
Eml,
that
user
will
use
to
install
the
Tecton
pipelines
most
of
the
tasks
we've
wrote.
We
send
it
to
the
Tecton
city
cataract
because
there
are
your
reusable
for
any
people
and
then
those
about
creating
the
pipeline
doing
the
pipe
renders
who's
executing
the
pipeline
run
and
then
do
it
manually
at
first,
and
this
is
what
we
did.
A
B
Working
on
it
yeah
it's
already
better
so
and
then
I
guess
we
sat
down
as
I
try
to
build
a
comparison
between
what
we
have
probably
what
we're
trying
to
do:
Tecton
and
yeah.
So
there
is
a
lot
of
red
and
yellow
on
the
right
side,
but
for
hook
we
introduced
the
triggers
project
we
mentioned
earlier
and
together
with
interceptor.
It
allows
us
to
do
something
similar
that
we
have
with
prowlin
hook.
So
this
is
actually
improving
and
is
getting
towards
the
green
now
for
the
job,
the
execution
life
cycle.
B
A
B
Everyone
is
to
have
access
to
this
information
for
tide.
We
don't
really
have
a
solution.
Today's
or
horologium
we
do
with
triggers
and
using
cron
jobs
from
kubernetes.
Hopefully
we
show
it
later,
and
garbage
collection
is
becoming
a
more
pressing
issue
for
us
now
that
this
has
been
running
for
a
while
and
we
are
getting
towards
the
thousands
and
thousands
of
tasks
runs
in
our
clusters.
B
So
brow
is
a
concept
of
agent
which
is
used
to
execute
a
certain
private
job
and
probable
ready
at
a
agent
for
Kennedy
builds.
A
new
agent
for
Tecton
pipeline
was
introduced,
so
we
started
using
that
for
our
initial
release.
Job
the
agent
will
provision
the
resources,
the
pipeline
resources,
specifically
the
get
resource
which
points
to
the
shot
at
get
shot
that
we
want
to
test,
and
it
will
also
generate
the
pipe
and
run,
and
this
is
what
the
prior
configuration
would
look
like.
B
But
yeah,
so
this
approach
word,
but
we
had
a
few
issues.
Issues
with
that.
First
of
all,
locks
are
not
integrated,
so
we
couldn't
use
liberators
as
we
used
before
with
this
new
solution.
So
we
were
okay,
running
jobs,
but
we
couldn't
have
access
to
the
logs
unless
we
went
on
the
cluster
and
look
at
the
other
logs,
they
are
directly
and
also
we
had
a
problem
with
the
dependency
prowl
from
testing
for
depends
on
old
version
of
Tecton
zero,
three
one
and
as
we
moved
along,
we
changed
interesting
features.
B
They
wanted
to
actually
use
the
latest
version
of
teknon,
always
because
well
that's
what
we
are
trying
to
do
dog
food
ourselves-
and
this
was
a
problem,
and
there
is
a
lot
of
inertia,
because
this
infra
is
a
big
is
a
big
repository
and
a
lot
of
people
depends
on
it,
so
making
a
change
there.
It's
not
something
that
you
do
from
today
to
tomorrow
and.
A
So
the
next
step
after
trying
out
the
pipeline
agents
of
pro,
was
okay
and
now,
if
we
really
want
to
use
choose
our
own
version
of
Tecton,
we
need
to
deploy
Tecton
the
latest
version
somewhere,
and
you
can't
really
deploy
two
version
of
tech
town
on
the
same
cluster.
It
doesn't
work,
one
will
take
over
the
other
one.
This
is
always
design.
Why
now
we
could
improve
that,
but
that
was
not
initial
goal
of
tech
time,
so
we
decided
to
have
a
new
cluster
just
dedicated
to
doc.
Putting
this
has
some
hedva
changes
right
right.
A
The
first
one
is
we:
can
it's
a
great
fill
experiment,
so
we
can
do
anything
we
want.
We
can
break
everything
it
shouldn't
matter,
at
least
at
first
once
people
from
the
project
will
depend
on
this.
We
this
will
change,
but
we
can
introduce
services
in
parallel
to
pro.
We
can
experiment
with
log
collecting
or
whatever,
and
and
do
not
need
to
run
anything
that
pro
runs.
It's
risk
free
environment.
We
can,
we
don't
we're
not
afraid
of
breaking
anybody
right
now
we
can
increment
you
roll
out
new
production
services.
A
B
Yeah,
so
one
of
the
first
issues
we
had
to
solve
there
was
that
we
want
logs
to
be
available
publicly
to
everyone,
and
we
didn't
have
a
solution
for
that.
So
we
built
a
small
application
that
provides
basically
us
with
access
to
to
the
logs
at
least
work
for
Google
Cloud
still
depends
on
the
stack
driver
for
certain
jobs.
We
also
have
an
alternative
like
for
the
releases.
We
also
have
the
ability
now
to
pull
the
logs
and
store
them
in
the
bucket,
along
with
the
release
file
for
the
nightly
releases.
A
And
then
the
next
part,
so
the
release
we
would
do
were
either
a
manual
or
on
the
pro
cluster.
So
the
step
we
started
to
work
on
was
doing
releases
progress
so
just
tacked
on
using
Tecton
using
cron
jobs
and
using
it
again
you
should
be
able
to
do
a
release
of
Tecton
or
any
projects
in
the
Tecton
CD
organization,
and
so
we
ended
up
doing
that
using
triggers
so
that
triggers
release
like
one
month
ago
was
the
best
thing
that
happened
and
now
we
are
trying
to
so.
A
This
is
the
what
an
eye
clear
is
generates.
So
there's
the
regional
you
can
install
and
there's
the
logs
of
the
builds
and
now
we're
trying
to
do
everything
else
code.
So
we
are
trying
to
put
in
place
inside
Tecton
some
rules,
guidelines
and
best
practices
on
how
we
can
and
that
any
tasks,
definition
and
any
Python
definition
inside
your
own
repository.
This
is
a
work
in
progress,
but
we're
trying
to
do
that.
B
B
We
have
a
nightly
job,
one
for
every
image
that
we
depend
on
in
our
infrastructure
and
we
just
use
figures
with
cron
jobs
to
to
trigger
them,
and
there
is
a
cool
thing
that
you
can
also
trigger
trigger
them
on
demand
that
we
show
that
later
we
just
have
a
small
problem
with
garbage
collection
and
another
interesting
thing,
we're
doing.
We
still
rely
on
prowlin
so
we're,
even
though
we
are
building
more
and
more
on
Tecton
side.
B
We
still
have
production
prowl
that
we
depend
on
heavily
and-
and
we
had
the
issue
in
the
past-
that
we
change
the
configuration
of
probably
forgot
to
apply
to
the
cluster.
So
we
started
doing
CD
of
product
configuration,
but
using
Tecton.
So
we
have
a
job,
an
hourly
job
that
runs
every
hour
and
deploys
the
latest
product
on
figuration.
And
the
next
thing
that
we
want
to
do
is
then
start
deploying
detecting
resources.
B
We
rely
on
as
well
on
a
regular
basis
from
the
plumbing
project
and
then
also
from
the
other
Tecton
projects,
so
that
we
incrementally
CD
everything
that
we
rely
on.
The
last
thing
that
we
want
to
get
to
is
to
deploy,
continues
to
deploy
tectum
services
themselves
and
run
them
from
the
nightly
releases
on
the
production
cluster.
We're
not
quite
there
yet.
B
A
So,
right
now
we
are
missing
CI
with
Tecton,
so
it's
definitely
possible
to
do
but
right
now
we
any
project
in
the
Tecton
city
organization
relies
on
pro
jobs
for
the
CI
part,
so
any
any
build
on
the
PR
are
using
pro.
So
this
is
something
we
need
to
fix
using
triggers
interceptors
and
stuff
like
this.
We
can
do
it,
but
we
are
just
trying
to
find
the
best
way
to
to
to
do
that
in
in
a
way.
A
A
We
need
some
testing
for
plumbing
so
right
now
we
are
because
we
are
in
like
a
risk
with
risk
free
environment.
We
can
do
some
stuff
without
really
have
retest
our
resources
or
service
configuration.
Sometimes
we
end
up
with
like
the
release.
The
Nyhuis
is
not
working
for
two
weeks
because,
because
we
didn't
test
something
this,
this
is
something
we
need
to
fix.
We
need
to
have
some
product
like
dashboard,
so
the
technology
dashboard
is
a
good
candidate
for
this.
We
just
need
to
work
more
on
making
it
usable
in
our
environment.
A
We
need
some
chat,
but
integration,
although
we
are
trying
we
we
are
we
going
to
remove
something
around
these
lines.
We
really
need
tied
like
management
or
integration,
so
something
that
would
once
the
PR
is
ready
to
merge
would
check
if
it
needs
to
be
replaced,
it
gets
master,
rerun
the
builds
and
then
merge.
So
this
is
something
we
are
missing
and
maybe
we
should
integrate
directly
with
the
tied
service
or
write
our
own.
This
is
something
we
need
to
decide.
B
Along
the
way
we
found
that
we
missed
some
bolt
or
some
features
in
even
some
some
projects,
so
there
are
things
that
we
need
to
add
to
Tecton
to
make
it
more
usable.
That
is
actually
what
we
wanted
to
find
out
with
this
exercise
of
doing
dog
fooding
one
use
case
that
we
found
a
lot
of
this.
It
will
be
good
to
finally
type
of
closest,
oh
say:
okay,
well,
I
ran
this
task,
but
whatever
happens,
I
still
want
to
do
this
at
the
end
and
we
need
support
for
output
parameters.
B
That
is
something
that
we
can
emulate
with
buckets
now,
but
we
need
to
have
more
native
support
for
that.
Optional
inputs
would
be
really
helpful
to
make
tasks
more
reusable
and
same
for
resources,
we're
working
on
notification.
This
is
in
the
design
phase,
or
it's
actually
designed
and
needs
to
be
implemented
now.
B
B
A
B
B
And
so
this
generates
triggers
of
webhook,
which
is
then
ended
by
triggers
and
it
goes
into
an
interceptor.
The
interceptors
validates
that
the
token
is
valid,
so
that
is
actually
get
that
is
talking
any
other
third
party,
so
I'll
just
do
and
then
this
is
the
the
dashboard
which
is
hooked
into
the
dog
fooding
cluster
and
yeah.
So
there
is
a
new
build
that
is
started.
A
B
E
E
A
A
A
I'm
gonna
talk
for
me
and
my
one
of
my
money
verdure
was
to
to
use
to
make
sure
that
the
product
we
were
building
was
useful
and
would
would
fit
our
needs
because
if
it
doesn't
fit
on
it,
it's
not
gonna
fit
anybody
needs.
So
that's
that
was
the
first
one
and
then
it
was
about
Pro
is
like
complete,
complex
piece
of
software
and
and
and
we
want
to
have
something
simpler,
and
that
was
but
the
first
one
was
to
very
that's
where
we
were
doing
is
actually
something
that
works.
Yeah.
C
A
The
dependency
we
have
on
this
year
on
plumbing
is
really
just
because
we
are
using
g-cloud
for
four.
We
are
using
gke
for
our
cluster
and
stuff
like
this,
but
Tecton
itself
has
no
dependency
on
anything,
so
you
should
be
able
to
use
whatever
your
two
is.
Whatever
your
provider
is,
and
if
you
need
to
push
images
or
to
use
I
don't
know
for,
if
you
will,
you
need
to
use
to
deploy
something
on
g-cloud,
you
would
use
the
G
cloud,
some
G
cloud
images.
B
We
actually
do
use
a
detector
on
different
clouds
and
just
know
I
mean
there
are
a
few
things
like
access
to
the
cluster
that
maybe
cloud
specific,
so
we
started
discussing
about.
Maybe
we
should
run
our
CI
test
on
different
clouds
that
involves
getting
more
resources
donated
to
the
city
F
and
then
we
can
consume.
But
it's
something
that
we
are
discussing
yeah,
because.
A
D
A
So
Jamie's
ex
is
using
Tecton
as
runtime,
so
the
the
yeah
Mel
you
write
in
Jenkins
X
to
define
your
builds
and
some
triggering
and
some
stuff
like
this
is
getting
translated
to
Tecton
resources
and
then
Tecton
handles
the
rest
and
then
they
add
other
values
on
top
of
it,
environment
and
stuff.
But
they're
using
like
it's
the
same
way.
Communities
use
some
CRI
implementation.
B
B
In
fact,
we
are
building,
as
you
have
seen,
multiple
components
and
the
philosophy
is
always
to
make
small
components
with
a
small
footprint
that
do
one
job
well
and
that
you
can
pick
and
choose
so
you
can
do
all
Tecton,
but
you
can
use
any
other
CI
city
system
using
Tecton
as
an
engine
for
the
pipeline's.
You
could
even
use
figures
to
create
resources
that
are
not
necessarily
Tecton
resources,
for
instance,
so.