►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Tekton State of the Union - Dibyo Mukherjee & Al Huizenga, Google Cloud
With the current spotlight on software supply chain security, you may have heard of Tekton - a cloud native open source framework for creating secure continuous delivery systems. In this session, we will share what is new and upcoming in Tekton as we make progress towards providing SLSA guarantees and releasing V1 of Tekton Pipelines.
A
Foreign
good
morning,
we
should
introduce
ourselves
first.
My
name
is
Al
heisenga
and
I.
Am
the
product
manager
at
Google,
Cloud
responsible
for
Google's
contributions
to
techtone
I.
Don't
make
too
many
of
the
contributions
myself
I
just
cheer
on
my
engineers
and
that's
basically
what
John
and
here's
one
of
them.
B
B
A
Know
the
State
of
the
Union
of
it's
a
big,
thriving
Community.
There's
lots
of
stuff
happening
that
we're
not
aware
of,
and
that
always
surprises
us,
but
what
we're
going
to
do
is
maybe
just
curate
some
of
the
things
that
tecton
has
done
in
the
past,
what's
important
now
and
then
looking
forward
where
we're
going
to
probably
see
areas
of
focus
as
technology.
A
So
that's
today,
yeah
so
I
was
looking
at
the
commit
logs
for
the
core
project,
the
court
repo
for
tecton,
which
is
the
pipelines
project
to
get
a
sense
of
where
things
began.
This
is
from
2018.
It
isn't.
The
very
first
commit
it's
probably
the
first
substantive
commit
it's
from
Christy
Wilson
who
still
works
at
Google.
Not
everybody
mentioned
here
does,
but
she
does
a
few
others
do
as
well,
and
it's
really
interesting.
A
She
has
a
book
actually
that
just
came
out
the
other
day
called
grocking
continuous
delivery,
which
is
really
exciting,
and
she
was
kind
of
fundamental
in
the
early
stages
of
tecton.
You
can
see
she's
saying
here:
I've
been
working
on
a
straw,
man
proposal
right
for
adding
a
pipeline
crd
and
for
possibly
involving
I
love
the
fact
that
there's
a
typo
in
it
I
think
that's
really
great,
and
then
she
also
included
a
diagram,
a
very
simple
diagram
of
tecton
Core
Concepts
that
still
really
kind
of
holds
water
and
I.
A
A
A
We're
working
hard
to
get
them
to
allow
us
to
name
them
and
celebrate
them
and
to
create
some
user
stories
that
we
can
share.
I
did
pull
out.
Some
anonymized
quotes
from
my
notes,
as
I've
been
talking
to
tecton
practitioners
over
the
last
six
months
and
I
won't
read
them
all
here.
We'll
share
the
slides
and
you
can
go
through
them,
but
there
are
some
really
interesting
patterns
like
invariably,
when
you
talk
to
somebody
about
why
they
picked
Tech
Tom,
because
there's
lots
of
other
tools
that
are
out
there.
A
They
have
a
goal
having
to
do
with.
Somebody
says
here:
I
think
in
the
first
one
managing
CI
by
convention,
not
just
by
configuration
so
really
the
driving
idea
is
they
want
to
have
a
well
established
and
standardized
patterns
for
their
pipelines
that
they
can
use
to
support
their
very
big
application,
engineering
teams
and
usually
you're
talking
to
a
devops
team.
A
That's
like
you
know
two
or
three
people
and
a
dog
or
whatever
right
and
so
they're,
trying
to
punch
above
their
weight
and
do
something
that's
really
hard
at
scale,
which
is
de-risk
continuous
integration
for
their
application.
Engineering
teams
and
tecton
is
really
well
designed
to
do
that.
To
help
them
do
that.
B
All
right,
so
we've
been
working
on
a
lot
to
get
to
you
know
the
CDF
graduation
stage,
so
you
know
under
edit
a
lot
of
the
work
to
like
get
us
there,
but
behind
the
scenes,
like
we've,
also
been
getting
very
close
to
a
V1
launch
for
our
the
core
pipelines.
Api
that
Al
has
been
talking
about,
so
pipelines
is
sort
of
like
the.
A
B
Of
the
project
where
you
get
to
like
Define,
your
CI
CD
pipelines
and
the
goal
behind
our
V1
launch
is
sort
of
to
have
like
a
well-tested,
stable
release
of
pipelines
that
you
can
use
to
build
production
like
Facebook
cicd
systems,
on
top
of
so
with
V1
is
supposed
to
be
launched
next
month,
November
for
tecton,
and
with
that
you
know,
we
will
have
no
new
backwards
and
compatible
changes
to
like
the
core,
the
very
core
V1
API.
So
you
can
be.
B
You
know
rest
assured
and
guaranteed
that
you
can
like
build
on
top
and
you
have
like
the
the
guarantee
of
the
the
same
feature
existing.
We
are
also
moving
into
a
Cadence
of
like
four,
like
supported
long-term
releases
model
for
tecton.
So
previously
we
used
to
do
like
you
know
a
release
every
month,
and
you
know
we
would
do
best
effort
like
patching
in
security
vulnerabilities
and,
like
updates
and
Bug
fixes,
and
things
like
that
with
V1
and,
like
you
know,
graduation
we
are
trying
to
like
make
it
even
more
stable.
B
B
So
that's
on
the
stability
axis
of
the
work
we've
been
doing,
but
at
the
same
time
we
have
also
been
like
adding
in
like
a
lot
of
cool
features,
and
you
know
I
could
spend
an
hour
talking
about
any
of
these.
But,
like
you
know,
we'll
just
like
do
like
a
very
condensed
version,
a
really
cool
one
is
remote
resolution,
which
you
know
you
can
have
your
pipelines
and
your
tasks
directly
from
git
repos
and
like
be
used
within
tecton.
So
you
don't
have
to
manage
like
extra
crds
on
the
cluster.
B
For
yourself,
we've
been
trying
to
make
it
a
little
bit
easier
to
do
work
with
like
more
structured
inputs
and
outputs
using
like
object,
parameters
and
results.
You
know
tecton's
always
had
this
capability
for
you
to
design
your
own
like
graph
of
tasks
that
you
want
to
Fan
in
and
pan
out,
but
with
Matrix
we've
really
made
it
super
simple
for
CI
use.
Cases
to
like
do.
Matrix
builds
compute
resources,
you
know,
tecton
is
built
on
kubernetes
and
then
you
know,
managing
cluster
resources
efficiently
has
been.
B
You
know,
it's
it's
a
very
tricky
problem,
so
we've
done
a
lot
of
effort
to
like
make
sure
that
you
can
actually
specify
exactly
what
compute
resources
that
you
want
efficiently
at
the
task
level,
and
then
you
know
go
from
there.
And
finally,
you
know
there's
a
lot
of
yaml
and
tecton.
So
we've
been
doing
a
lot
of
work
to
like
reduce
the
verbosity
of
yaml,
while
still
maintaining
the
overall
like
power
and
flexibility
that
tecton
is
well
known
for
so
that's
just
on
the
pipeline
side
of
things,
another
big
one.
B
You
know
like
we
just
heard
about,
like
you
know
the
software
Supply
the
secure
software
software
supply
chain,
and
then
you
know
we
have
tecton
chains
which
is,
like
you
know,
sort
of
our
the
tecton
project
that
provides
helps
you
get
to,
like
you
know,
salsa
Levels
by
default,
so
we
stacked
on
chains
will
provide
like
provenance
information
attestation
by
default.
It
will
sign
images,
and
recently
we
have
been
working
on
features
that
helps
you
sign,
not
just
images
but
other
kinds
of
artifacts.
B
So,
like
Maven
packages,
python
packages,
all
that
kind
of
stuff,
it
can
push
attestations
and
it
basically
allows
you
to
get
like
salsa
L2
right
now
and
we
are
like
hard
at
work
trying
to
get
it
to
like
salsa
L3.
So
you
know
just
using
tecton
and
chains.
You
should
be
able
to
like
get
to
a
very
you
know,
strong
guarantees
for
s3c
and
we're
trying
to
integrate
very
well
into
the
rest
of
the
ecosystem.
B
Around
software
supply
chain,
like
keyless
signing,
has
been
a
big
deal
like
you
know,
we
work
pretty
well
with
like
six
store
and,
like
you
know,
cosines
so
chains
will
use
like
cosine
to
sign
things.
We
are,
you
know
working
on
like
a
task
signing
and
verification
mechanism,
so
you
can
sign
your
task
and
see
which
tasks
are
signed.
Etc
we
are
featured
in
Fresca,
which
is
I,
can
never
say
this
right,
which
is
the
factory
for
repeatable
software.
B
A
Yeah,
as
dibio
said,
this
is
a
really
interesting
area
of
development
for
tecton
and
there's
a
lot
of
hairy
details,
so
everybody's
interested
in
chatting
with
us
about
it
afterwards.
I'll
do
my
very
best,
so
that
leaves
us
with
maybe
just
a
couple
of
minutes
to
talk
about
like
what's
coming
with
tecton
and
where
the
area
of
focus
is
going
to
be.
A
I
would
say
that
generally
I
don't
know
Andrea
if
you
think
I'm
wrong,
you
just
throw
something
at
the
stage,
but
I
feel
like
tecton
is
sort
of
transitioning
out
of
really
nailing
the
core
stuff
and
now
starting
to
sort
of
grapple
with
some
of
the
Practical
problems
and
challenges
of
integrating
tecton
and
production
systems
right.
So
this
has
to
do
with
management
at
scale.
This
has
to
do
with
interoperability
with
the
other
systems
that
tecton
has
to
coexist
with
as
part
of
the
complete
end-to-end
delivery
flow.
A
A
Catalog
environment,
where
different,
verified
Publishers
can
actually
maintain
and
manage
their
own
catalogs
and
artifact
Hub
supported
that
a
lot
more
elegantly.
So
that's
really
great
we're
working
on
just
task
signing
and
verification.
So
we
can
make
sure
that
everything
that's
shared
in
that
tecton
catalog
is
trustworthy.
A
A
So
could
you
please
sort
of
have
a
recurring
pipelines
or
pipelines
within
pipelines
so
that
you
can
manage
it
at
a
more
granular
level,
just
concurrency
management?
So
what
happens
when
you
have
pipelines
and
tasks
that
have
the
same
name
that
are
trying
to
run?
At
the
same
time,
can
you
have
a
configurable
rule
set
to
control
how
your
system
behaves?
A
Custom
tasks
is
a
big
deal
right.
Custom
tasks
is
basically
a
framework
to
do
things
that
aren't
sort
of
supported
by
core
tecton.
That
might
be
important
for
your
particular
environment
or
for
your
for
your
particular
CI
requirements.
Yes,
oh
you
like
that.
Oh
that's
your
project,
okay,
good
I
thought.
Maybe
I
got
it
wrong.
Git
integration!
This
is
a
really
important
one
like
a
tecton
integrates
well
with
GitHub
and
everybody
who's.
A
Implementing
tecton
has
some
flavor
of
I
triggering
workflows
based
on
things
that
happen
in
GitHub,
PRS
and
commits,
and
then
making
results.
Log
files,
the
status
of
pipelines
and
tasks
available
to
the
developers
who
live
and
GitHub
the
tecton
functionality
around.
This
is
still
fairly
raw
and
low
level,
which
is
fine,
because
tecton
is
a
flexible
framework,
but
there's
more,
we
can
do
to
just
create
more
built-ins
around
this
to
make
it
easier.
So
that's
what
workflows
is
all
about?
A
Dibio
actually
has
a
session
on
workflows
this
afternoon,
so
I'll
stop
before
I
steal
all
the
Thunder
and
finally
just
continuing
to
push
the
envelope
when
it
comes
to
secure
supply
chain.
So
this
stuff
gets
really
complicated,
but
in
a
nutshell,
it's
also
level
three
versus
level
two
has
to
do
with
moving
from
being
able
to
provide
attestations
about
the
provenance
of
the
of
the
tasks
and
the
artifacts
in
your
build
process
to
making
sure
that
that
Providence
is
unalterable
or
immutable.
A
Non-Fossil
falsifiable
and
so
we've
got
a
number
of
sort
of
planned
features
that
are
in
the
design
stage
now
aimed
at
helping
you
do
that.
One
of
them
is
an
integration
with
spiff
Spire,
which
is
an
implementation
of
spiff,
and
that's
very
it's
a
very
cool
framework
for
basically
for
workload,
identity,
identification
and
then
just
a
policy
layer
that
allows
you
to
control
what
happens
based
on
that
identification.
Verification
where
particular
verified
workloads
can
and
cannot
run,
for
example,
so
yeah
altogether.