►
From YouTube: Mario Meets the Robocat: Lessons From Dogfooding Tekton - Andrea Frittoli & Dibyo Mukherjee
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Mario Meets the Robocat: Lessons From Dogfooding Tekton - Andrea Frittoli, IBM & Dibyo Mukherjee, Google
Tekton is an open-source project providing lightweight reusable Kubernetes native building blocks for CI/CD that can be curated to embody best practices. Tekton, hosted by the CD Foundation, aspires to be the common denominator in CI/CD. At the last Kubecon, the speakers shared their adventures in incrementally adopting Tekton for its own release "plumbing". The goal was to ensure that the project was going in the right direction. Since then the speakers have focused their dogfooding efforts on Tekton’s CI needs. They set up event based pipelines to verify pull requests, test infrastructure defined as code, and provide friendly bots. In this talk, the speakers will share their experiences in using Tekton for its own CI/CD -- the challenges they encountered, how the robocat helped overcome them, the lessons learnt along the way, and how those helped shape the roadmap for Tekton.
https://sched.co/Zej2
A
A
Sure
so,
in
today's
talk
we
will
start
with
a
brief
introduction
to
techton
we'll
talk
a
little
bit
about
plumbing,
which
is
like
an
umbrella
term.
We
use
to
describe
our
dog
food
experiments
that
is
running
using
tecton
for
tecton.
We
will
do
a
deep
dive
into
tecton
continuous
integration,
how
we're
using
tecton
for
our
own
continuous
integration,
we'll
show
a
quick
demo
of
our
efforts
and
we'll
end
with
some
lessons
learned
and
future
work
over.
So
what
is
techdon
over
to
andrea.
B
So
tekton
is
a
framework
for
creating
a
ci.
Cd
pipeline
pipeline
can
be
run
from
in
any
kind
of
environment,
starting
from
your
laptop
or
in
a
cloud
whether
it's
on
premise
or
a
public
cloud.
So
it
gives
you
full
flexibility.
Tecton
is
an
open
source
software,
which
is
hosted
at
the
cd
foundation,
continuous
delivery
foundation.
B
B
B
Tekken
tries
to
create
building
blocks
that
can
be
used
in
this
space
and
integrate
well
with
many
other
solutions
that
are
existing.
Like
jenkins,
x,
scaffolding,
native
and
so
forth,
and
it
also
tries
to
do
the
job
on
the
specific
building
blocks
very
well
to
create
like
best
practices
for
running
tasks
and
and
pipelines.
B
A
Okay,
so
the
technon
universe
today
consists
of
a
few
different
projects
at
the
core,
our
pipelines,
which,
as
andrea
mentioned,
are
the
core
building
primitives
for
your
ci
cd
systems.
This
includes
steps,
pipelines
and
tasks,
we'll
go
into
a
little
bit
more
detail
about
these
in
the
next
few
slides
we
also
have
triggers
which
actually
allows
you
to
run
these
things.
Your
pipelines
continuously.
That
is,
it
allows
you
to
trigger
pipelines
based
on
events
complementing.
A
That
is
the
catalog,
which
is
where
the
community
can
share
usable
tasks
and
pipeline
definitions,
and
other
people
in
the
community
can
reuse
those
things,
and
then
we
have
a
hub,
which
is
a
web
interface
on
top
of
the
catalog,
so
think
something
like
docker
hub,
but
for
your
tecton
pass
next
up,
we
have
to
link,
we
have
dashboard,
which
is
a
nice
web
interface
for
your
techdown
installation.
You
can
look
at
your
pipelines,
tasks,
etc.
We
also
have
tkn,
which
is
a
powerful
cli
tool
for
interacting
with
tecton.
A
We
have
an
operator
to
manage
your
techdown
installation
and
your
tecton
upgrades.
Finally,
we
have
experimental.
So
this
is
a
repo
where
we
do
a
lot
of
our
experiments
with
tecton.
So
we
examples
of
experiments
would
include
things
like
storing
tasks
and
pipeline
run.
Results
in
a
variable
format,
experimenting
with
image
formats
for
bundling
your
tech
and
tasks,
pipelines
and
other
complementary
resources,
experiments
with
supply
chain
security
such
as
signing
and
verifying
bills,
etc,
etc.
A
So,
now
we'll
go
into
a
little
bit
more
details
about
technon
pipelines,
so
the
most
basic
primitive
is
a
step
which
is
which
is
basically
a
command
that
you
run
in
a
container.
You
can
specify
other
things,
such
as
volume
and
environment
variables,
but
the
step
is
the
most
basic.
Primitive
next
step
is
a
task.
A
task
is
a
sequence
of
steps
that
run
in
the
same
pod.
Tasks
run
to
completion
so
or
until
one
of
the
steps
in
a
task
fails.
A
A
pipeline
is
basically
a
graph
of
tasks
with
declared
inputs
and
outputs.
The
advantage
with
the
pipeline
is
that
you
can
run
your
tasks
in
parallel,
if
needed,
or
in
sequential,
to
form
your
entire
cicd
workflow.
So
steps,
tasks
and
pipelines
are
basically
how
you
define
your
ci
cd
workflow.
How
you
invoke
them
is
via
cast
run
and
pipeline
run
so
pipeline
run,
as
the
name
suggests
is.
One
invocation
of
a
single
pipeline
test
run
is
the
same
for
a
task
you.
B
Thank
you
debia.
So
once
you
have
your
pipelines,
you
may
want
to
trigger
them
manually
so
to
say
by
creating
a
pipeline
run,
but
in
the
large
majority
of
the
use
cases
you
may
want
to
run
a
pipeline
as
a
consequence
of
a
certain
event
that
happened.
Event
can
be
anything
triggered
by
a
service
in
the
cloud
or
service
that
you
rely
on
that
you
want
to
react
to
so
typically,
something
like
web
books
triggered
by
github
or
gitlab,
or
your
git
hosting
system.
B
So
techno
triggers
was
created
as
part
of
the
technon
to
handle
this
kind
of
use
cases
also
tekton
triggers
define
its
own
primitives.
The
first
one
is
the
event
listener,
which
is
the
component
which
receive
the
events.
The
event
is
received
over
http
or
https,
it's
composed
by
headers
and
payload,
and
can
come
directly
from
the
publisher
or
perhaps
through
event
broker,
and
so
the
next
primitive
is
interceptor,
because
you
may
not
want
to
process
all
the
events
that
you're
receiving
to
your
event
listener.
B
So
interceptors
were
defined
and
we
have
a
few
stock
ones
like
github,
gitlab
interceptors
that
are
able
to
first
of
all
validate
that
the
request
that
was
received
as
valid
and
verify.
The
token
is
a
correct
one
and
also
they
allow
to
to
filter
based
on
the
type
of
event
or
the
content
of
the
event,
and
they
are
extensible
it's
possible
to
define
custom
interceptor.
They
can
also
add
extra
content
to
the
payload
or
to
the
other
of
the
message.
B
So
the
next,
the
next
primitive
are
the
trigger
bindings.
That
trigger
binding
are
used
to
extract
relevant
information
from
the
headers
and
the
payload
of
the
incoming
message
into
parameters
that
are
then
passed
to
the
trigger
template,
which
is
the
final
primitive
triggers
trigger
templates,
are
defined,
as
the
name
suggests,
to
create
templates
for
the
resources
that
needs
to
be
triggered
as
a
result
of
the
event.
B
So
now
that
we
have
an
overview
of
what
tecton
is
we're
going
to
look
more
into
how
we
run
our
infrastructure
for
tecton
that
we
call
plumbing
of
mario's
plumbing?
So
if
you
look
in
the
dictionary
plumbing
is
the
system
of
pipes,
tanks
fittings,
another
apparatus
required
for
the
water
supply,
heating
and
sanitation
in
a
building
protectant?
B
This
means
the
combination
of
tools
and
configuration
that
we
use
to
builds
everything
which
is
needed
by
tekton
in
terms
of
automation,
which
means
and
includes
the
ci
system
that
we
use
for
tecton
itself
and
all
the
cd
tasks
for
tecton.
So
how
we
do
github's
reasons,
keeping
that
on
task
and
sync
their
cluster,
do
release
management
and
geared
up
github
organization
management,
for
instance,
and
up
to
you,
dpu.
A
Okay,
so
techno
the
project
was
created
out
of
the
k
native
serverless
project,
and
one
of
the
consequences
of
that
is.
We
inherited
the
same
ci
cd
system,
initially
that
they
use
so
key
native
and
a
lot
of
native
kubernetes
and
a
lot
of
other
projects
in
the
in
this
cloud
native
world
use
a
tool
called
pro,
which
is
a
kubernetes
based,
ci
cd
tool
that
was
built
for
the
kubernetes
project.
A
There
was
to
set
up
a
dedicated
cluster
for
our
dock
footing
experiments
so
we
set
up
a
kubernetes
cluster
just
to
do
that
and
finally,
we
also
tried
to
integrate
tecton
into
prop
so
prow
as
a
tecton
plug-in.
So
you
could.
Your
single
project
could
actually
run
your
technon
pipeline
if
you're
more
interested
in
details
of
the
early
days
of
our
dog
fooding
in
the
previous
kubecon
in
san
diego,
we
gave
a
talk
about
this
portion
of
our
dog
fooding
experiments.
A
So
next
up
once
we
had
those
basic
dog
fooding
steps,
the
next
step
was
to
actually
run
them
continuously.
By
this
time,
the
triggers
projects
had
its
first
release,
so
we
could
start
doing
this.
The
first
step
we
did
there
was
to
create
90
releases
for
all
of
our
techcon
projects,
and
we
did
this
using
a
combination
of
techconf
triggers
the
ground
pipelines
and
your
standard
kubernetes
cron
jobs.
So
now,
instead
of
an
engineer
having
to
manually
invoke
a
release,
you
could
just
have
nightly
releases
every
single
night
desktop
beyond
just
your
90
releases.
A
We
started
doing
nightly,
builds
for
infrastructure
containers,
so
this
is
not
just
code,
but
your
configuration
and
other
infrastructure
containers
that
we
might
need.
Once
we
had
these
92
visas,
we
needed
a
place
to
deploy
all
of
these
stuff,
so
we
created
this
cluster
called
the
robocat.
The
robocat
cluster
is
where
we
do
all
of
our
continuous
delivery
experiments.
A
So
we
set
up
our
techdown
triggers
and
our
tecton
pipelines
to
deploy
our
nitro
tecton
releases
to
the
robocod
cluster.
So
we
started
with
deploying
just
the
releases,
but
then
we
started
doing
more,
so
we
started
deploying
our
configuration
data,
config
maps,
other
techno
resources
such
as
tecton
pipelines
and
technon
tasks,
so
that
they
would
remain
in
sync
with
the
definition
in
our
git
repos,
and
we
did
more
than
just
that.
We
also
used
get
offs
and
in
combination
with
tecton
triggers
and
pipelines
to
automate
our
arc
management.
A
So
today,
if
you
want
to
join
the
technocd
arc,
you
add
yourself
to
a
file
in
our
community
repository
open
a
pull
request.
Once
the
request
gets
purged,
we
have
a
trigger
listing
and
that
that
will
which
will
trigger
a
task
that
will
add
you
to
the
arc
by
itself.
So
that
was
how
we
ended
up
doing
continuous
delivery
for
for
techno
using
techdom.
B
B
First,
we
validate
the
token.
Then
we
filter,
based
on
the
repo
that
generated
the
trigger
and
the
type
of
event.
It
could
be
a
pull
request
or
a
comment
or
other
type
of
events,
and
we
are
also
working
on
setting
up
a
filter
for
verifying
that,
whether
a
user
belongs
to
the
tecton
city
or
or
not,
and
because
not
not
all,
of
the
events
from
github
are
identical
in
terms
of
content
as
well,
and
so
we
need
to
do
some
work
to
adapt
them,
and
this
is
where
overlays
come
into
play.
B
B
A
B
And
then
we
have
event
specific
bindings
on
top,
so
the
resulting
set
of
parameters
that
is
extracted
from
the
headers
and
payload
of
the
github
event
is
then
passed
to
a
trigger
template
and
ultimately
to
the
pipelines
in
the
middle
of
the
feature
here.
So
we
have
a
few
different
trigger
templates.
B
We
have
one
trigger
template,
which
contains
ci
jobs
that
are
common
tool
repositories,
and
this
is
great
because
it
allows
us
to
define
a
few
jobs
for
checks
that
we
want
to
enforce
on
all
repositories.
And
then
we
have
trigger
templates,
which
are
ripple
specific,
like
for
the
plumbing
repo,
we
host
our
infrastructure.
B
We
have
a
set
of
pipelines
that
are
shown
here
in
the
middle.
In
each
pipeline
we
have
the
purple
diamonds,
they're
conditions
and
they're
used
to
optimize
execution
of
ci
jobs
in
the
sense
that
we
don't
always
need
to
run
all
the
jobs
that
are
defined
in
our
infrastructure,
because,
for
instance,
some
of
the
job,
they
will
build
a
container
image
and
we
have
multiple
container
images.
B
So
we,
it
only
makes
sense
to
run
the
jobs
to
build
the
container
images
that
have
been
modified
within
the
pr
that
we
are
testing
so
after
the
conditions
are
passed
if
their
conditions
are
passed.
The
actual
ci
job
in
the
blue
blocks,
which
is
a
task,
is
executed.
So
I
think
we're
doing
things
like
linting,
the
gold
code
and
the
yaml
running
unit
tests,
building
container
images
and
so
forth.
B
B
So
we
just
updated
the
task
and
the
pipelines
and
all
the
resources
in
the
cluster
directly,
but
once
we
started
having
one
or
two
production
jobs,
we
could
not
do
that.
So
we
didn't
want
to
go
really
trial
and
error,
modify
the
job.
Cfci
started
running.
That
was
not
the
biable
solution,
so
we
decided
to
build
a
way
to
that.
Allows
us
to
test
the
ci
changes
in
ci
itself,
which
has
a
number
of
benefits.
B
So,
first
of
all,
it
removes
the
need
to
have
access
to
the
ci
cluster,
which
is
also
good
practice,
but
also
enables
people
who
does
not
have
access
to
the
production
cluster
to
do
changes
on
ci
and
test,
and
it
reduces
the
need
for
own
infrastructure
to
run
a
copy
of
ci
system
on
your
own
infrastructure.
And
it's
also
very
helpful
for
shooting,
because
imagine
that
you're
doing
a
change
even
not
to
the
ci
system
even
to
the
pipelines.
And
you
see
a
failure.
A
B
So
you
can
alter
the
ci
job
to
inject
more,
very
positive,
for
instance,
or
inject
more
information,
so
that
the
next
time
it
runs.
It
will
show
you
the
information
that
you
need
to
troubleshoot.
What's
going
on
so
the
way
we
achieve
this,
it's
that
we
deploy
in
isolation
within
a
namespace,
a
copy
of
the
ci
system,
which
is
seeded
out
of
the
pr.
B
So
I'm
going
to
demonstrate
this
using
the
plumbing
repo,
which
is
where
we
store
our
infrastructure
definition
and
our
container
images
definition
as
well.
So
I
have
a
branch
ready
here,
there's
a
very
small
change
to
one
of
the
our
container
images.
It
changes
the
release
version.
This
is
for
the
hub
image
that
we
use.
B
Okay,
so
the
pr
is
created-
and
here
I'm
watching
the
tecton
ci
namespace,
which
is
where
we
run
our
ci
jobs,
and
you
can
see
that
five
pipelines
are
started
right
away.
So
here
we
have
things
like
this
test:
tecton
ci,
which
is
a
special
job
which
is
used
for
the
testing
ci
use
case,
and
otherwise
we
have
hub
build
decking,
building
gypsy
dlp.
B
Those
pipelines
are
there
to
run
to
build
container
images,
and
then
we
have
the
golden
blinker
and
you
see
that
some
of
the
jobs
are
completing
right
away
very
quickly
in
a
few
or
20
seconds
or
so.
And
if
we
look
at
the
list
of
the
tasks
that
are
running
in
this
namespace,
you
see.
Some
of
them
are
very
long
links
that
include
check,
git
check
names
and
some
of
them
are
failed.
B
So
these
are
actually
the
the
checks,
the
diamonds
in
the
picture
that
show
earlier
and
they
are
filtering
out
some
of
the
ci
jobs,
and
this
explains
why
some
of
the
jobs
were
failing
so
quickly
and
you
can
see
that
the
hub
build
is
still
running
because
we
modified
the
hub
image
and
the
linter
is
still
running.
Oh
no,
it's
actually
just
finished
and
we
can
go
and
look
at
this
into
github
directly
refresh.
B
We
have
our
new
vr
here,
so
we
open
the
pr-
and
we
can
see
here
our
free
aci
jobs
and
if
I
look
click
on
the
details
for
the
hub,
for
instance,
I
can
see
here
in
the
tecton
ci
namespace
our
pipeline
is
running
and
the
build
image
task
is
running.
So,
oh,
unfortunately,
it
failed.
So
I
click
on
it
and
have
a
look
at
what
went
wrong.
So
I
got
a
lot
of
information
info
details.
B
These
are
probably
not
very
relevant
to
me,
so
it
just
says:
okay,
it
failed,
and
here
it's
it's
a
bit
abrupt.
I
guess-
and
here
is
the
error
so
well.
It
looks
like
release.
2
was
not
really
a
good
idea,
so
maybe
we
should
try
to
make
this
ci
job
a
bit
more
friendly
and
roll
back
our
changes
as
well
as
the
next
step.
B
Vr,
so
this
is
a
file
in
the
plumbing
repo,
where
we
host
the
definition
of
the
some
of
our
ci
jobs.
In
this
case,
I'm
looking
at
the
build
which
tanika
kanika,
which
he
used
to
build
container
images.
So
what
I'm
going
to
do?
I
want
to
make
the
job
a
little
bit
more
friendly,
so
we
let
us
tap
into
it.
B
B
B
B
And
if
you
look
at
the
pipelines
that
run
for
the
second
time
you
can
see
this
one
was
marked
as
the
tecton
ci
was
markedly
succeeded
and
all
the
others
are
marked
as
completed
completed
is
a
sign
that
something
was
kept
inside
the
pipeline
and
in
fact,
if
you
look
at
the
tasks,
you
will
see
that
we're
several
failed
ones.
So
this
means
all
these
jobs
were
not
executed.
B
B
B
B
And
this
time
we
can
notice
that
the
namespace
is
different.
Here,
we've
got
pr28
and
the
job
looks
a
bit
different,
so
we
have
our
hello
kubecon,
stop
and
then
the
build
and
push
still
failed,
because
I
did
not
update
this
number,
but
we
don't
have
all
the
information
that
was
there
before
and
we
don't
need
so
we
could
test
a
new
ci
change
live
and
this
completes
the.
A
Sure,
thank
you
adrian
for
the
demo,
so
fixing
our
price
aka
future
work.
So,
first
off
what
did
we
learn?
In
the
beginning,
we
made
all
the
mistakes
actually
still
we're
making
all
the
mistakes.
You
know
simple
things
like
not
verifying
inputs,
overriding
or
previous
release,
etc.
So,
basically,
all
of
the
manual
errors
that
you
can
imagine,
so
we
sort
of
fixed
some
of
that
by
using
automation,
triggers,
etc.
We
also
beyond
just
your
tasks
and
pipelines.
A
There
is
a
lot
of
yaml
if
you
notice
the
diagrams
that
andrea
showed
there
is
a
lot
of
moving
parts,
so
there
is
a
lot
of
boilerplate.
We
have
started
using
customize,
which
helps
quite
a
bit,
but
in
the
future
we
are
looking
at
custom
tasks
or
tsls
that
might
actually
make
this
stuff
a
little
bit
more
concise
testing
changes
to
the
ci
setup
is
hard,
especially
locally,
though
with
a
system
like
the
one
that,
under
a
demo
that
becomes
quite
a
bit
easier
tracing
is
a
big
problem,
so
you
have
started.
A
We
heavily
used.
Labels
like
on
radio
showed
labels
and
annotations
and
standard
kubernetes
tooling,
but
some
kind
of
like
more
inbuilt
integration
would
be
very,
very
nice.
We
also
realized
that
not
everything
needs
to
run
a
spot
for
tasks
such
as
like
a
weight
test
that
you
probably
don't
want
to
create
a
part
that
just
waits
for
two
hours,
so
we
are
working
on
that.
We
also
realize
the
value
of
documentation,
as
always
like,
there's
always
documentation.
There
could
always
be
more
so
based
on
some
of
our
our
lessons.
A
We
are
doing
a
lot
of
work,
so
we
are
looking
at
what
we
call
the
new
pipes
that
we
are
building,
so
we
have
task
results
which
will
allow
us
to
clean
up.
Do
clean
up
of
our
name,
spaces,
etc
and
things
like
notifications
much
more
easily.
We
have
simple
conditionals
where
a
new
condition
does
not
spin
up
a
new
pod.
We
are
looking
into
exploring
more
complicated
pipelines
using
switches
and
loops.
A
We
are
looking
into
bundling
your
tecton
tasks,
your
pipelines,
your
conditions,
all
of
that
into
a
bundle
that
can
be
referenced
into
like
a
image
registry
sort
of
similar
to
a
docker
image.
That
would
help
a
lot.
We
are
doing
a
lot
of
more
experimentations
on
metrics
and
debugging
and
tracing,
and
how
to
do
that
better.
A
We
mentioned
custom
tasks
where
users
can
bring
in
their
own
kind
of
tasks
that
don't
necessarily
have
to
spin
up
a
new
pod.
Each
time
we're
experimenting
with
making
triggers
easier
so
that
we
can
a
user
can
just
write
their
trigger
configuration
without
having
to
deal
with
how
to
expose
the
event
listener
for
the
event
listener.
A
We
are
looking
at
using
event
listeners
as
a
k
native
service,
so
you
get
all
the
benefits
of
a
serverless
service
and
finally,
we're
looking
at
ephemeral
credentials
so
that
when
something
goes
wrong,
you
don't
have
to
change
all
of
your
long
rift
secrets
at
once,
but
instead
we
have
security
built
in
by
default
by
using
short,
live
tokens
using
something
like
the
github
app
specifically
for
the
doc
footing.
Ci
side.
A
A
Instead
of
building
our
own
tasks,
we
are
looking
at
using
end-to-end
tests
for
technon
pipelines,
easily
testing,
not
just
tecton
changes
to
your
ci
pipeline,
but
infrastructure
containers
running
our
tests
on
more
clouds,
instead
of
just
google
cloud,
improving
our
ci
service
monitoring,
improving
the
monitoring
of
our
ci
services.
So
when
something
goes
wrong,
we
have
a
easy,
we
know
easily
what's
going
wrong
and
finally
moving
some
of
our
slash
commands
to
using
tekton,
instead
of
so
with
that
I'll
turn
it
over
to
andrea.
B
B
So
we
here
aim
to
be
a
friendly
with
coming
community,
so
come
and
join
us.
I
mean
whether
you're
a
user.
You
want
to
share
your
use
cases
or
your
stories,
issues
that
you've
encountered
or
whether
you
want
to
come
and
contribute
or
call
the
documentation
or
just
hang
out
with
us.
We
are
on
slack
and
here
is
a
link
to
the
to
join
the
community
on
slack
and
yeah.
B
So
here
is
a
thank
you
for
listening
to
the
our
talk
today
and
thank
you
christy
for
the
great
drawings
that
you
provided
us
with
for
for
our
talk
and
yeah
here
is
a
number
of
links
and
references.
You
can
use
to
get
started
on
tecton
and
to
get
in
touch
with
us
and
the
slides
will
be
shared
after
the
conference.
So
don't
worry,
you
will
have
access
to
all
these
links
and
thank
you
again.
A
A
A
Okay,
we're
just
gonna
yeah
we're
just
gonna,
go
start
with
the
oldest
one
first
and
go
through
them.
So
I'm
gonna
read
out
the
oldest
question:
first
andre.
If
you
want
to
answer
then
maybe
we
can
switch
or
we
can
figure
that
out.
Okay,
so
first
question
was:
we
are
at
greenfield
starting
with
openshift.
Do
you
think
we
can
capitalize
on
techton
for
ci
and
cd.
B
B
So
there
is
also
another
questions
on
reddit.
Openshift
provides
stackton
argo
cd,
both
as
operators.
Do
they
complement
each
other?
You
can
use
them
both
and
yes,
you
can
they
don't
specifically
integrate
with
each
other,
but
you
can
definitely
complement
the
two
of
them.
You
can
use
tekton
for
automating,
some
of
your
pipelines,
ci
side,
for
instance,
and
then
see
the
argo
cd
from
the
cd
needs.
B
A
I
can
jump
to
the
next
question
I
saw
there
were
a
few
questions
about
getting
the
link
to
the
slides
which
are
now
up
on
shed,
so
please
go
check
that
out
I'll
skip
to
number
seven,
which
says:
tecton
can
be
user
in
a
vanilla
way,
defining
native
pipelines,
but
is
also
hidden
in
other
tools
that
abstract
its
functionalities
like
jenkins
x,
is
that
right,
techton
is
a
foundational
project.
In
the
sense
it
can
be
used
to
build
other
cicd
tools.
Yeah.
A
B
Okay,
so
we
had
a
question
about:
do
you
somehow
archive
your
pipeline
runs?
We
have
kept
a
crd
inside
the
cluster,
so
this
is
a
very
good
questions
and
do
we
clean
up
unnecessary
ones?
So
today
for
cleanup,
we
used
chrome
jobs,
basically
to
clean
things
out,
and
you
can
use
labels
or
annotation
to
select
things
that
you
want
to
keep
in
your
cluster,
but
we
don't
have
an
active
facility
for
that.
We
do
have
an
experimental
project.
B
A
B
Okay,
I
can
take
this
one
too,
so
decton
as
stevia
said,
this
tends
to
be
not
very
opinionated.
So
with
other
solutions,
you
might
find
some
more
constraints
or
more
opinions.
How
you're
going
to
set
up
your
pipelines,
whether
they
are
ci
or
cd
pipelines.
So
depending
if
you
need
like
a
quick
head
start,
and
you
want
to
have
something
to
get
up
and
running
really
fast
on
a
full
solution
or
you
want
to
have
the
full
flexibility
and
building
blocks
and
usability.
B
So
you
may
go
one
direction
or
the
other,
so
you
can
for
sure
also
use
tekton
for
certain
aspects
and
argo
city
for
others
as
well.
So
you
don't
have
to
just
necessarily
choose
between
the
two.
It
very
much
depends
on
your
use
cases,
and
the
next
question
is:
how
do
you
manage
permission
inside
tecton
dashboard
to
each
team,
see
only
their
tasks
and
pipelines?
B
So
we
don't
have
ability
in
dashboard
today
to
like
login
with
accounts,
but
it
is
possible
to
deploy
the
dashboard
with
scope
on
specific
namespaces.
So
you
can
have
multiple
instances
of
your
dashboard
that
are
only
accessible
by
different
teams,
and
they
can
then
restrict
visibility
in
terms
of
pipelines
and
tasks.
Also,
the
dashboard
can
be
deployed
both
in
full
mode
or
also
in
reality,
mode
which
you
use
in
the
public
dashboard
for
tactile.
A
Okay
moving
on
do
we
require
a
kubernetes
cluster
for
running
tucked
on
pipelines.
The
answer
today
is:
yes,
though
we
the
way
we
build
our
apis
today
is
to
make
sure
we
are
not
super
coupled
to
kubernetes,
so
that
in
the
future
we
can
support
more.
But
today,
yeah
you
need
a
kubernetes
cluster
to
run.
Tecton
next
up
is
is
step
down,
cli
image
supported
on
multi
architecture
platforms.
I
know
we've
been
doing
some
work
on
like
supporting,
like
ibm,
c
series,
etc,
and
that's
like
ongoing
work.
B
A
B
I
can
take
this
one,
so,
as
I
was
saying,
tecton
is
not
really
united,
so
it
doesn't
like
really
give
you
like
off
the
shelves
structure
like
pipelines
for
doing
cd,
but
you
can
definitely
automate
this
kind
of
setup.
Like
these
trains,
we
use
tekton
to
run
our
releases
for
tecton
and
if
you
want
to
have
things
like
manual
approval
steps
between
releases
reasons,
to
move
the
release
across
multiple
environments.
B
We
are
working
and
defining
things
like
custom
tasks
that
will
allow,
in
the
future
to
have
a
task
which
is
not
necessarily
about
running
in
a
kubernetes
cluster,
but
a
generic
event
that
you
might
want
to
to
have
in
your
pipeline.
It
could
be
like
manual
approval
or
any
kind
of
integration
within
the.
A
System,
if
my
org-
oh
sorry,
I've
skipped
one,
we
are
seeing
a
bottleneck
using
tecton,
which
is
that
you
cannot
specify
the
resources
to
the
pod,
which
means
we
are
unable
to
run
resource,
demanding
bills
and
tests,
otherwise
that
otherwise
the
tool
works.
Awesome
correct
me
if
I'm
wrong
and
rare,
but
I
think
you
should
be
able
to
specify
limits
on
on
your
test,
runs
right.
Language.
B
Yes,
it
is
possible,
we
have
a
plot
template
that
can
be
used
in
the
runs
so
yeah,
it's
definitely
possible
because
the
the
steps
in
our
containers
that
are
executed
in
the
pot
when
you
have
multiple
steps
in
a
task.
What
we
do
we
take
the
maximum
resources
limits
for
for
the
largest
step,
and
we
use
that
as
the
one
to
be
used
for
the
product,
because
they're
going
to
be
executed
sequentially.
So
we
don't
want
to
request
the
resources
for
the
whole
set
of
steps
together.
A
Sounds
good
next
up
was
the
overhead
of
a
whole
kubernetes
cluster
protect
on
not
worth
it.
Would
a
one
note
cluster
be
acceptable?
Does
it
play
nice
with
k3s?
So
techno
is
very
lightweight
right
now.
If
the
controller
is
just
a
single
part
deployment,
if
and
then
the
scalability
basically
then
depends
on
how
much
what
kind
of
workloads
you're
running.
So
if
you
want
to
get
started
with
a
onenote
kubernetes
cluster,
you
should
be
able
to
just
try
it
out
with
that
and
given.
A
A
A
B
A
B
A
As
I
understand,
techdown
creates
a
new
part
for
every
job,
so,
okay,
yeah,
creating
a
new
part
for
every
job,
is
how
tech
time
works
today,
but
we
are
working
on
a
new
feature
called
custom
tasks
where
you
should,
where
you'd
be
able
to
define
your
own
tasks
and
where
fastness
don't
necessarily
create
their
own
pods.
So
an
example
might
be
something
like
a
weight
task,
where
you
won't
spin
up
a
pot
and
sleep
for
five
minutes
or
something
so
something
like
that.