►
From YouTube: Tekton Project Showcase - Christie Wilson, Jason Hall
Description
Tekton Project Showcase - Christie Wilson, Jason Hall
Join us for KubeCon + CloudNativeCon in Shanghai June 24 - 26 and San Diego November 18 - 21! 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.
A
Hi
everybody
I'm
Christy,
Wilson
I'm,
a
software
engineer
at
Google
over
the
years,
I've
worked
in
a
lot
of
different
industries.
I've
worked
in
mobile
foreign
currency
exchange,
triple-a
games,
but
no
matter
what
I
try
to
work
on
I
always
end
up,
gravitating
back
towards
work,
related
to
testing
and
CICP,
and
so
for
me,
Google
has
been
no
exception
and
right
now,
I'm
very
excited
to
be
leading
the
Tecton
project,
which
is
what
I'm
going
to
be
talking
to
you
about
today.
A
So
we're
gonna
start
off
with
an
intro
to
Tecton
and
an
overview
of
how
it
works
and
then
we'll
get
into
some
demos,
so
I'll
be
showing
you
a
demo
of
Tecton
pipelines
and
then
I'll
be
welcoming
to
the
stage
Vincent
Demi
stare
to
demo
the
CLI
and
Simon
Kagi
to
demo.
The
dashboard,
then
we'll
talk
about
some
ways
that
you
can
integrate
with
Tecton
and
we'll
finish
off
with
where
we're
going
in
2019.
A
So
how
many
people
have
some
idea
of
what
Tecton
is
okay,
pretty
good
and
who
has
no
idea
and
is
hoping
I'll?
Explain
it
perfect?
You
are
in
the
right
place.
So,
let's
start
off
with
the
back
story,
so
some
of
you
might
know
that
Tecton
actually
started
as
part
of
the
K
native
project,
so
in
20
18,
K
native
serving
was
created.
A
So
this
is
a
way
to
have
an
open
source
server
list
solution
built
on
kubernetes
and
in
order
to
have
that
there
needed
to
be
a
way
to
go
from
source
to
a
deployment,
and
that's
why
Kay
native
build
was
created
soaked
a
native,
build.
Let
you
build
images
in
kubernetes
which
it
turned
out.
People
wanted
just
that
functionality
alone.
They
thought
it
was
pretty
cool,
but
they
quickly
wanted
to
add
more.
They
wanted
to
run
tests
before
their
builds
and
they
wanted
to
create
more
complicated
pipelines.
A
A
So
a
Tecton
is
all
about
is
cloud
native,
CI,
CD
components
that
are
composable
and
reusable
and
portable
between
vendors.
So
we
took
a
lot
of
what
we
were
already
doing
in
CI
CD
for
years,
and
we
added
a
declarative,
typed
interface
on
top
of
it.
So
the
goal
here
is
that
eventually
you
should
be
able
to
start
a
project
and
no
matter
how
complicated
the
pipeline
is.
A
So,
even
though
we
started
with
pipelines
and
pipelines
are
still
at
the
core,
the
project
has
expanded.
So
now
we
also
have
a
CLI
tool
and
a
dashboard
and
we're
currently
incubating
some
event
triggering
projects
as
well
and
we're
not
doing
this
alone.
We
have
regular
contributions
right
now
from
engineers
at
cloudBees,
Red,
Hat,
IBM
and
Salesforce,
and
we've
put
a
lot
of
effort
into
trying
to
make
it
really
easy
for
new
contributors
to
join
us.
So
if
you're
interested,
please
please
come
by
and
check
out
our
contributing
guide.
A
So
before
we
get
into
the
demo,
is
I'd
like
to
tell
you
a
bit
about
how
Tecton
pipelines
works.
So
it's
all
about
cloud
native
components,
and
here
cloud
native
means
the
same
thing
that
it
means
for
a
lot
of
us.
So
it's
an
open
source
project.
It's
built
around
containers
and
the
containers
are
orchestrated
with
kubernetes
now
to
understand
how
the
pipeline's
work.
The
first
thing
to
understand
is
that
they
are
implemented
with
CR
DS,
so
CRE
d
stands
for
custom
resource
definition
and
it's
a
way
of
extending
kubernetes
itself.
A
So
out
of
the
box,
kubernetes
comes
with
types
like
pods
and
services
and
deployments,
but
with
CR
DS,
you
can
add
additional
types,
and
then
you
provide
binaries
called
controllers
that
act
on
those
types.
So,
let's
take
a
look
at
the
types
we
have
extended,
kubernetes
with
for
Tecton
pipelines,
our
most
basic
building
block
is
something
we
call
a
step,
and
this
step
is
actually
an
existing
kubernetes
type
called
a
container
spec.
This
is
an
image
with
everything
that
you
need
to
run
it
like
what
environment
variables
it
needs,
what
volumes
etc.
A
A
The
next
new
type
is
called
a
pipeline
and
a
pipeline
combines
tasks.
So
now
you
can
run
these
tasks
in
any
order.
You
want,
it
can
be
sequential,
they
can
run
in
pair
or
you
can
create
complicated
graphs,
they're
not
guaranteed
to
execute
on
the
same
node,
but
via
the
inputs
and
outputs.
You
can
take
the
outputs
of
one
task
and
you
can
provide
them
as
inputs
to
another
task
and
so
being
able
to
make
these
more
complicated.
Graphs
can
really
speed
up
your
pipelines.
A
So
tasks
and
pipelines
are
types
that
you
define
once
and
then
you
use
them
again
and
again,
just
creating
them.
Doesn't
do
anything
they
just
sit
there
in
the
cluster
and
wait
until
you
create
our
next
new
types
which
are
pipeline,
run
and
tasks
run
and
those
actually
invoke
the
pipelines
and
tasks.
And
then
our
final
new
type
is
the
one
that
you
use
to
provide
runtime
information
like
what
image
registry
to
use,
what
git
repository
and
that's
called
a
pipeline
resource.
A
So
for
Tecton
pipelines,
we've
extended
kubernetes
with
five
types
all
together
we
have
tasks
that
are
made
of
steps.
We
have
pipelines
that
are
made
of
tasks,
and
then
we
actually
run
those
using
pipeline
runs
and
task
runs,
and
we
provide
runtime
information
with
pipeline
resources
and
separating
out
those
runtime
information
gives
us
a
lot
of
power.
A
Okay,
so
prepare
to
see
a
lot
of
yeah
Mille,
so
pipelines
combine
tasks.
So
let's
take
a
look
at
some
of
the
tasks
that
we
can
be
dealing
with
so
in
this
pipeline.
We're
going
to
use
this
task,
which
is
called,
build
push-
and
you
can
see
in
this
definition
here
all
of
the
inputs
and
outputs
that
this
task,
so
it
needs
a
git
repository
as
an
input.
It
needs
some
parameters
and
as
an
output,
it's
going
to
be
building
an
image
and
then
here
you
can
see
the
steps
that
are
involved.
A
So
it's
going
to
be
using
the
canna
Co
tool
to
actually
build
and
push
the
image
and
then
we're
going
to
also
be
using
this
task
here,
which
is
going
to
invoke
cube
cuttle
to
deploy
to
our
cluster
and
over.
Here.
You
can
take
a
look
at
the
pipeline
that
uses
these
tasks.
So
at
the
beginning
the
pipeline
has
to
declare
the
resources
it
needs.
A
So
we
can
see
that
it
needs
a
git
repository
and
it's
going
to
be
using
two
different
images,
and
since
we
know
what
tasks
it's
using,
we
can
guess
it's
probably
going
to
be
building
two
different
images
and
down
here
in
the
actual
tasks.
We
can
see
it's
referring
to
the
build
push
tasks
that
we
were
looking
at
twice,
which
means
it's
going
to
be
building
two
different
images
and
then
later
it's
going
to
be
using
the
deploy
task
that
we
were
looking
at
to
deploy
as
well.
So,
let's
create
those
with
one
hand.
A
And
to
actually
invoke
them,
we're
going
to
create
a
pipeline
run,
so
this
is
a
pipeline
run.
We
can
see
that
it's
referring
to
the
pipeline
that
we
were
looking
at
before,
and
it's
actually
and
it's
providing
the
three
resources
that
pipeline
needs.
So
it
needs
a
git
repository
and
it
needs
two
images
and,
for
example,
this
git
repository
is
provided
as
a
pipeline
resource
here,
and
we
can
see
that
this
is
the
repository
it's
acting
against,
and
this
is
the
revision
it's
using.
So
let's
apply
that.
A
A
Okay,
so
here
we
can
see
thanks
Dan,
we
can
see
the
pipeline
run
in
action,
so
you
can
see
that
it
was
broken
down
into
a
number
of
tasks
runs
which
are
all
referring
to
the
tasks
that
we
were
looking
at
and
if
we
wanted
to
see
what
was
going
on,
we
can
further
take
a
look
at
the
pods.
So
let's
take
a
look
at
the
logs
for
this
pod.
A
Okay,
so
here
you
can
see
that
this
task
is
executing
and
it's
using
Kanna
code
to
build
and
push
the
image.
So
now.
One
thing
that
you
may
have
noticed
is
that
I'm
using
coop
cuddle
a
lot
and
there's
a
lot
going
on:
that's
not
related
to
Tecton,
but
is
specific
to
kubernetes
that
you
have
to
understand
to
know
what's
happening.
So
at
this
point,
I'd
like
to
introduce
Vincent
Demi
stare,
who
is
going
to
demo
the
CLI
tool
that
he
and
his
team
have
been
working
on.
B
Can
people
okay,
perfect
all
right
so
I'm
instantly?
Mr.
obviously
I
work
at
reddit
and
CLI
project
on
Tecton
and
the
past
month
on
the
CI
and
I'm
gonna
show
you
the
C
right.
So
the
CLI
is
here
to
prove
to
provide
you
a
command
line
that
is
focused
on
the
pipeline
objects,
and
so
you
can
use
it
without
any
prior
knowledge
of
the
actual
cube
command
and
yeah
Mel.
B
So
please
bear
in
mind
that
the
project
is
about
one
month
old,
so
the
future
set
is
currently
quite
small,
but
we
are
going
to
add
more
and
more
on
the
past
few
months,
so
the
command
line
is
called
chicken
and,
as
you
can
see,
we
can.
We
have
four
useful
subcommands
pipeline
pipeline
runs
tasks
intestines.
So
let's
just
list,
for
example
the
pipeline's
we
have
available
on
the
cluster,
and
we
can
see
the
pipeline
Christie
just
created.
We
can
also
list
the
actual
tasks.
B
In
which
keyword
right
now,
so
we
have
the
free
tasks
same
thing.
We
can
just
list,
for
example,
the
task
runs
here.
We
can
see
all
the
tasks,
trends
and
their
name,
so
all
of
those
were
created
by
the
pipeline
run
and
if
I
want
to
filter
like
at
some
point,
it's
gonna
have
a
lot
of
tasks
run,
probably
in
your
cluster.
If
I
want
to
filter
them
by
I,
don't
know
one
task:
reference
I
can
just
type
the
name
of
the
task,
and
it's
going
to
show
me
only.
B
The
tasks
run
related
to
the
task
build
push.
And
finally,
we
can
just
list
the
pipe
and
run
and
see
if
they
succeeded
or
not,
and
for
example,
this
is
the
actual
run
and
the
last
thing
I'm
gonna
show
you
is
the
logs.
So
if
you
want
to
see
the
logs
of
the
pipeline
or
a
task
using
cube,
CTL
you're
gonna
have
to
look
at
the
status
of
the
task
and
then
find
the
pod
name
in
there
and
then
do
the
cube
GTL
logs.
B
A
B
All
for
the
CIO
so
far
we
are
gonna,
add
more
like
detailed
visualization
of
your
pipelines
or
the
steps
in
your
tasks,
outage
figure
and
create
tasks
without
knowledge
of
without
using
cube,
CTL,
but
sometimes
I
would
switch.
Sometimes
you
don't
need
my
command.
I
now
are
awesome,
but
sometimes
you
need
a
web
UI
like
a
dashboard,
and
for
that
I
would
like
to
introduce
you.
Simon
kg
will
demo
the
chips
each
year,
the
chips
to
the
Tecton
dashboard
projects.
C
C
We
see
it's
similar
in
spirit
to
the
kouhei's
dashboard,
because
when
we
first
created
the
dashboard,
we
wrote
a
whole
whack
of
JavaScript
creating
custom
renderings
for
all
the
various
Tecton
resources.
But
what
we
found
is
that
doesn't
work
in
the
long
haul,
and
these
are
things
that
I
think
sig,
UI
and
six
CLI
is
found.
So
now
we're
much
more
metadata
driven
and
we're.
Looking
to
cig
you,
a
cig,
UI
and
six
CLI,
to
help
us
with
things
like
versioning
desk
discrepancies,
which
are
which
are
things
that
are
going
to
be
critical
for
Tecton.
C
We're
not
imagining
that
the
detect
on
dashboard
is
going
to
be
it
be
the
be-all
and
end-all
of
all
CIC
duis,
so
we're
building
it
out
of
reusable
components
and
we're
also
building
in
an
extension
mechanism.
So
the
idea
here
is
that,
although
you
might
not
be
using
the
Tecton
dashboard,
you
can
always
go
there
to
take
a
look
at
our
components
and
get
ideas
for
how
you
might
want
to
do.
Some
of
the
tougher
tasks
like
rendering
a
task
dag
or
look
at
our
lists
and
details.
Views.
C
C
If
you
look
at
it,
you
might
think
Oh
everything's
hierarchical,
a
pipeline
breaks
into
pipeline
runs
breaks
into
tasks
runs,
but
what
you
actually
discover
is
that
there's
there's
actually
connections
all
the
way
through,
so
you
might
be
able
to
go.
You
can
travel
from
a
toss
run
up
to
a
toss,
so
there's
some
unique
navigational
concepts
that
we're
working
through
in
in
Tecton,
alright.
So
now
I'm
going
to
show
you
a
quick
demo
of
recorded
demo
of
where
we
were
actually
last
night.
C
So,
as
I
say,
this
is
this
is
where
we
are
in
terms
of
development
as
of
last
night,
notably
things
that
are
missing
that
are
going
to
be
added
very
soon
as
a
search
bar
at
the
top.
This
is
really
critical.
When
you're
navigating
around
into
pipelines,
you
use
labels
a
lot
down
the
left.
We
have
our
categories.
C
C
What
I'm
going
to
do
now
is
I'm
going
to
drill
into
a
pipeline,
so
we
get
a
new
pipeline
run
list
view.
There
will
be
a
detail
view
there
here.
We
have
tasks
a
list
of
tasks
and
within
the
tasks
we
have
steps
and
you
can
look
at
them
and
see
logs,
which
is
just
a
cat
of
a
file,
the
step,
the
size
of
the
step
and
the
details.
So
you
can
actually
see
what
the
step
was
running
in
the
first
place
across
the
right.
We
have
pipe.
C
C
The
log
view
is
marked
down.
We
can
we
can
render
glyphs
and
links,
and
so
this
one
failed
because
we
couldn't
push
to
Christy's
cat
factory.
Repo
namespaces
are
just
filters,
so
I
actually
ran
this
on
IBM's
kubernetes
service,
but
there's
no
kubernetes
resources
in
search
service
by
default.
Extensions
are
another
piece.
That's
really
critical.
So
right
now
we're
doing
experiments
in
triggers,
but
your
need
gonna
need
to
provide
UI
for
that.
And
how
do
you
go
about
doing
that?
C
And
we
also
believe
that
the
types
of
extensions
that
you're
going
to
use
there
are
going
to
vary
quite
quite
dramatically.
So
what
we
have
right
now
is
something
that
lets
you
extend
and
build
in
just
about
any
UI,
that's
on
top
of
the
kubernetes
CR
DS,
but
in
the
future,
we're
looking
to
make
extensions
that
you
can
have
without
having
to
write
any
JavaScript
at
all,
just
built
on
the
pure
metadata
that
kubernetes
has
so
in
this
way.
C
C
So
one
of
the
ideas
we're
playing
around
with
this
when
you're
viewing
a
particular
pipeline
run,
you
might
want
to
see
the
current
pipeline
run,
but
you
also
might
want
to
see
the
pipeline
run
before,
and
so
this
is
especially
useful
when
the
current
pipeline
run
has
just
failed,
so
you
can
immediately
get
back
to
the
the
last
passing
pipeline
run
again.
Another
really
difficult
problem
is:
how
do
you?
How
do
you
display
these
DAGs?
C
A
A
The
first
and
most
obvious
option
is
just
to
use
Tecton
directly,
so
this
means
that
you
would
be
running
Tecton
and
your
users
would
be
using
all
of
the
Tecton
types
like
pipelines
and
tasks
to
interact
with
it.
So
this
will
give
you
the
most
advantage
of
the
Tecton
features,
but
some
of
the
things
that
you
need
to
actually
make
this
happen
or
currently
works
in
progress,
and
also
it
means
that
your
users
will
be
using
the
Tecton
syntax,
which
some
people
find
really
verbose
a
related
option.
A
A
Something
else
you
can
do
that
takes
advantage
of
the
interface
and
also
takes
advantage
of
the
catalog
is
to
implement
the
interface
yourself.
So,
even
though
it's
a
kubernetes
based
interface,
it
doesn't
actually
have
to
be
implemented
with
kubernetes.
So
if,
for
some
reason
you
have
restrictions
that
make
it
so
you
don't
want
to
use
kubernetes,
you
could
use
this
option
so
that
you
have
the
same
interface.
A
You
can
support
all
the
tasks
in
the
catalog,
but
you
can
control
everything
that
happens
underneath
the
option
that
we're
seeing
most
commonly
right
now
is
for
you
to
create
your
own
DSL,
which
can
compile
down
into
Tecton
types.
So
this
means
that
your
users
would
be
interacting
with
your
DSL,
but
you
could
provide
if
you
wanted
a
break
glass
mode
so
that
if
users
need
to
go
beyond
what
your
DSL
provides,
they
can
actually
go
straight
into
the
Tecton
types.
A
The
biggest
downside
here
is
that
supporting
compilation
from
your
DSL
to
Tecton
and
then
also
the
other
way
if
Tecton
back
to
your
dsl
might
be
impossible.
So
you
might
actually
lose
lose
a
little
bit
in
what
pipelines
you
can
have
people
bring
to
your
application
and
what
they
can
bring
out
to
others,
and
then
a
similar
approach,
which
is
pretty
much
the
same
thing,
but
without
the
break
glass
mode
is
to
hide
Tecton
completely.
A
So
in
this
mode
you
would
lose
a
lot
of
the
Tecton
advantages,
but
you
could
still
use
some
of
the
cool
stuff
that
we're
working
on
like,
for
example,
the
ability
to
run
multiple
steps
on
one
pod
in
order
and
to
have
sidecar
support,
but
you
don't
have
to
get
tied
into
Tecton.
This
can
also
be
a
good
option
if
you
want
to
try
it
out,
but
you
don't
want
to
expose
your
users
to
it,
and
you
want
to
wait
for
our
API
to
solidify
a
bit
and
then
maybe
the
simplest
option.
A
That
would
be
the
least
work
is
to
just
invoke
Tecton
from
your
tool.
So
we
were
hearing
about
spinnaker
earlier.
This
is
similar
to
how
spinnaker
it
integrates
with
Jenkins,
in
that
you
can
have
spinnaker
pipelines
that
call
out
to
Jenkins
jobs
and
then
watch
those
jobs
and
wait
for
them
to
finish.
You
could
do
a
similar
thing
with
Tecton,
so
there
are
a
lot
of
different
options
here
and
the
things
to
consider
when
you're
evaluating
them
are.
Do
you
want
your
users
to
be
interacting
with
Tecton
syntax
directly?
A
How
easy
do
you
want
it
to
be
for
people
to
bring
their
own
pipelines
to
your
tool
and
whether
you're
using
kubernetes,
and
can
you
handle
the
fact
that
the
API
is
currently
in
alpha
and
might
actually
be
changing?
And
so
speaking
of
the
API
being
in
alpha,
let's
finish
up
with
a
look
at
what
we're
doing
with
Tecton
in
2019.
A
A
So,
specifically,
the
missing
features.
We're
working
on
right
now
are
event,
triggering
log
persistence
and
support
for
SCM
tools
like
github
and
get
lab,
and
so
the
goal
here
would
be
that
you
would
be
able
to
set
up
triggering
from
your
github
or
git
lab
project
straight
to
a
Tecton
pipeline,
but
using
only
Tecton
components
and
then
for
the
rest
of
the
year.
We
have
a
somewhat
ambitious
list
of
features
that
we
want
to
add.
A
lot
of
these
are
things
that
most
see.
A
Icd
tools
already
have
things
like
conditional
execution
or
manual
approval
via
pause
and
resume,
and
then
we
want
to
add
some
things
that
other
see.
Icd
tools
tend
not
to
have
like
strong
typing
around
images.
We
want
to
have
a
strong
extension
model
so
that
you
can
extend
Tecton
with
your
own
types
without
having
to
recompile
it
or
upstream
the
changes,
and
so,
if
you're
interested
in
this,
please
come
to
our
working
group
meetings
and
join
our
mailing
list.