►
From YouTube: Building a cloud native CI/CD pipeline
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
hi,
everyone
thanks
for
joining
us
today
for
another
cncf,
live
webinar
building
a
cloud
native
CI
CD
pipeline
I'm,
Libby,
Schultz
and
I'll,
be
moderating
today's
webinar
I'm
going
to
read
our
code
of
conduct
and
then
hand
things
over
to
Jason,
Smith
and
Muriel
McCabe,
both
with
Google
a
few
house
keeping
items
before
we
get
started
during
the
webinar
you're,
not
unable
to
speak
as
an
attendee.
But
there
is
a
chat
box
where
you
can
list
all
your
questions
and
we
will
get
as
many
as
we
can
at
the
end.
A
This
is
an
official
webinar
of
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
of
all
fellow
participants
and
presenters.
Please
also
note
the
recording
and
slides
will
be
posted
later
today
to
the
cncf
online
programs,
page
at
community.cncf.io,
under
online
programs
they're
also
available
via
your
registration
link
and
the
recording
will
be
available
on
our
online
programs.
A
B
All
right
well,
thank
you
for
the
introduction,
Libby
and
thank
you
everybody
for
joining
us
today.
As
mentioned,
we
are
going
to
be
talking
about
building
a
cloud
native
pipeline
cicd
platform
rather,
and
it
is
going
to
be
very
open
source
very
heavy
and
we
hope
to
a
very
Cloud
native
heavy
and
we
hope
you
enjoy
it
just
to
get
a
few
introductions
out
of
the
way
looks
like
I'm
having
information,
so
my
camera
get
keeps
getting
turned
off
so
we'll
just
do
it
this
way.
B
So
just
a
brief
introduction
here
on
Jason
Smith,
you
can
call
me
Jay
I'm
an
app
equals
specialist
customer
engineer
at
Google
Cloud.
You
can
find
all
of
my
links
and
there's
probably
a
few
I
need
to
update
at
linktree.
My
peer
Reviewer
is
winry.
She
is
often
you
know,
heard
barking
in
my
meetings
or
sitting
in
my
lap
right
now,
she's
sitting
at
my
feet
and
Muriel
I
will
turn
over
you
to
introduce
yourself.
C
C
There
at
the
bottom
is
my
peer
reviewer
Orion,
Russian
blue,
who
loves
to
at
very
inopportune
times,
walk
across
the
keyboard,
but
of
course,
he's
just
doing
that
to
make
sure
that
all
my
code
is
linked
and
sanitized.
So
thank
you
all
again
for
being
here
and
just
as
a
final
note,
we
are
excited
to
be
here.
Our
opinions
are
our.
B
C
So
today,
as
mentioned,
we
are
going
to
be
covering
a
cloud
native
approach
to
cicd,
but
there
are
you
know
very
many
things
that
fall
under
this
world
of
cloud
native
and
cic,
so
we
are
going
to
scope
that
pretty
definitively
and
look
at
some
specific
Tooling
in
that
space
in
particular
Argo,
CD
and
tecton,
and
then
from
there
we're
actually
going
into
some
live
demos,
as
Libby
mentioned,
we
will
try
to
get
to
all
of
the
questions
at
the
end,
but
just
since
we
want
to
make
sure
we
can
cover
all
of
our
material.
C
C
C
Well
for
all
of
you,
folks
that
have
been
running
kubernetes
in
different
capacities,
you
probably
have
experienced
firsthand
just
how
not
easy
this
might
be,
but
when
we're
also
looking
at
Cloud
native
and
CI
CD,
that's
actually
one
of
the
powers
of
being
able
to
have
your
configurations
and
your
applications
defined
in
code
is
that
ability
to
take
those
yaml
templates
actually
now
will
Empower
you
to
be
able
to
do
a
lot
of
really
great
things
when
it
comes
to
looking
at
continuous
delivery
and
continuous
integration.
C
So
moving
on
now,
when
we're
looking
at
the
world
of
devops,
you
know
there
are
also
very
many
things
that
fall
under
this.
This
devops
world
we're
looking
at
this
slice
that,
in
particular,
falls
under
the
realm
of
both
release,
engineering
and
devops,
particularly
The
Continuous
delivery
and
deployment
part.
But
every
team
implements
this
in
a
slightly
different
way
and
this
means
very
different
things
across
teams,
so
for
some
we're
looking
at
some
some
different
processes,
such
as
you
know,
agile
or
stand-ups
or
continuous
integration.
C
So
well,
what
does
devops
actually
look
like
when
it
comes
down
to
your
organization?
So,
as
mentioned
we're
we're
going
to
now
take
a
quick
definition
check.
These
are
actually
all
part
of
the
glossary,
or
these
have
come
from
the
cncf
glossary.
It's
an
open
source
glossary.
You
can
actually
contribute
definitions,
but
really
these
are
different
terms
that
fall
under
the
cloud
native
world.
So
when
we're
talking
about
things
like
continuous
integration,
integrating
code
changes
as
regularly
as
possible.
This
is
really
looking
at
the
build
portion
of
your
CI
CD
and
release
pipeline.
C
So
building
your
images
going
in
that
inner
loop
of
development,
where
you're
taking
your
code,
committing
it
to
your
repository
having
built,
generated,
doing
testing
and
so
on,
and
ideally
this
is
something
that
is
happening
on
an
ongoing
basis
very
frequently,
multiple
times
per
per
day.
C
Now,
what
we're
going
to
be
focusing
on
as
I
mentioned
today
is
really
on
this
second
half
of
the
CI
CD
pipeline.
Looking
at
one
there's
the
continuous
delivery
portion
of
it,
where
now
it's
taking
those
changes
and
the
code
that
has
been
created
in
this
inner
loop
of
development
and
now
deploying
that
into
your
environment,
where
you
can
actually
see
and
test
out
the
the
code
or
see
the
application
running
and
then
a
step
further
Beyond.
C
C
So
we'll
continue
on
yep
back
one
okay,
there
we
go
so
now
when
we're
looking
at
some
of
these
characteristics
or
guidelines
around
Cloud
native
devops
or
Cloud
native
CI,
CD
Pipelines,
one
portion,
which
you
know
so
one
portion
is
get
ups
and
you
may
be
saying
right
now,
while
we're
talking
about
our
code
code
and
build,
doesn't
get
apps
have
to
do
with
infrastructure.
Well,
yes,
so
one
really
key
principle
is
now
that
your
build
and
your
release
systems
are
actually
systems
of
their
own.
C
That
need
to
be
managed
in
certain
ways
and
to
be
able
to
manage
those
systems
using
a
lot
of
the
same
methodology
such
as
infrastructure
as
code
and
so
on,
to
be
able
to
ensure
the
resilience,
the
scaling
and
so
on,
of
your
build
systems
themselves.
So
that's
another
key
component
is
that
you
have
this
tooling.
That
can
also
be
managed
in
very
much
the
same
way
as
your
code
is
managed.
C
Another
really,
a
big
principle,
which
also
kind
of
Falls
in
line
with
the
get
apps
methodology,
is
now
looking
at
having
some
a
separation
of
both
your
application
source
code.
C
So
the
actual
functions
and
features
and
logic
of
your
application
and
the
application
configuration
so
maybe
your
destination,
if
we're
looking
now
at
the
kubernetes
world,
the
repositories
with
the
actual
manifests
and
so
on,
because
now
your
application
is
a
little
bit
more
than
just
the
code
that
you're
running
you
actually
have
configurations
such
as
the
services,
the
endpoints,
any
of
your
config
maps
and
secrets
and
configurations
as
well.
So
these
are
all
components
that
now
are
decoupled
from
your
application
source
code.
C
When
we're
looking
at
the
centralized,
devops,
tooling
kind
of
goes
back
to
just
the
get
Ops
and
being
able
to
have
all
of
your
configurations
and
infrared
defined
as
code
we're
taking
a
very
container
Centric
development
approach,
just
to
really
lie
into
the
portability
and
the
reusability
of
your
systems,
and
essentially
what
we're
looking
at
is,
with
this
portability
being
able
to
now
decouple
certain
parts
of
your
CI
CD
pipelines,
where
your
your
build
and
your
deployment
pipelines,
don't
necessarily
have
to
be
tightly
a
couple
of
these
can
be
decoupled
as
well.
C
Automation,
you
know,
is
another
key.
Devops
principle
across
the
board
is
also
very
important
in
the
cloud
native
world,
the
frequent
mergers
and
deploys,
and
additionally
looking
at
just
that
movement
of
now
being
able
to
shift
left
and
and
do
more
of
the
testing
and
security
early
on
in
the
build
process
rather
than
after
the
fact,
when
something
is
running
already
in
production.
That
security
and
testing
is
now
going
to
be
baked
in
across
the
board.
B
Thank
you,
Muriel,
and
so
one
thing
we
want
to
talk
about
that's
out
of
scope,
at
least
for
this
conversation.
Not
for
the
concept
of
devops
in
general
is
like
deployment
strategies.
What
we're
not
going
to
really
talk
about
blue,
green
Canary,
rolling,
updates,
deploying
functions,
ml
data
pipelines,
devops
is
kind
of
a
large
scope.
So
a
lot
of
times
the
concept
of
devops
can
be
integrated
into
other
forms
of
computing,
not
just
in
terms
of
deploying
applications
but
functions
ml
data
pipelines.
B
We'll
talk
a
little
bit
about
that
conceptually,
but
not
go
into
depth
and
we're
not
going
to
talk
about
infrastructure
automation.
So
you
know
infrastructure
is
code.
Anything
like
that.
This
is
all
stuff
that
can
be
covered
over
devops.
You
know
we
we
might
do
an
you
know
webinar
series
or
blog
series
on
it
later,
but
for
the
purpose
of
this
conversation
we
won't
be
covering
that.
B
So
we've
been
talking
about
devops.
This
is
called
a
cicd
platform
webinar.
What?
What
what's
the
difference?
One
thing,
I
always
point
out
is
devops
isn't
really
a
tool
like
when
we
hear
the
word.
We
often
think
of
it
as
a
tool,
or
you
know
you
might
go
on
to
LinkedIn
and
look
up
devops
engineer
job
stuff,
like
that.
Devops
is
really
more
of
a
philosophy
and
a
platform,
a
philosophy
and
an
execution
of
said
philosophy
into
a
set
of
tools
and
whatnot.
B
It's
how
we
decide
to
deploy
applications
and
how
do
we
make
that
work
in
such
a
way
that
it
is
repeatable?
That's
why
we
have
kind
of
this
infinity
symbol
here
where
we
go
from
planning
to
coding,
building,
test
release,
deploy,
operate,
Monitor
and
then
we
start
all
over
again
and
that's
how
we
continue
to
reiterate
and
improve
our
application,
fix
bugs
all
of
that
and
continue
to
have
that
application
constantly
evolving
over
its
life
cycle
and
then
also
integrating
new
light
applications
or
new
workloads
into
the
life
cycle
over
for
our
entire
stack.
B
But
you
know
you
might
see
a
lot
of
these
names
that
you've
seen
before
most
of
these
are
open
source,
but
there's
also
proprietary
stuffs
out
there,
but
we
love
open
source
here
at
cmcf
and
Google
and
personally
I've
been
a
huge
open
source
fan
for
decades
now
so
yeah.
This
just
gives
you
a
quick
idea.
You
might
see
here
that
towards
the
top,
there
are
two
particular
ones:
continuous
integration,
continuous
delivery.
Those
are
where
we're
going
to
focus
mainly
on
today
in
the
devops
stack
and
I
also
took
the
screen
grab
here.
B
So
if
you
go
to
landscape.cncf.io,
you
kind
of
get
this
as
I
call
an
eye
charts
of
all
the
different
projects
and
companies
that
are
supporting
the
entire
landscape
of
cncf.
Here,
in
particular,
are
the
various
companies
and
projects
that
make
up
the
application,
development
and
CI
CD
toolkit.
Some
of
these
again,
you
might
be
very
familiar
with
two.
In
particular.
B
We're
going
to
talk
about
today
are
tecton
and
Argo,
but
any
one
of
these
is
great
we're
not
necessarily
saying
that
tecton
and
Argo
the
end
all
be
all,
but
whatever
works
for
your
organization.
That's
why
we
say
devops
as
a
philosophy
versus
like
an
actual
platform.
We
don't
say
these
are
the
absolute
tools
you
need
to
use.
B
So
almost
all
coding
begins
in
some
kind
of
IDE,
whether
it
is
hosted
web-based
or
on
your
own
laptop,
so
something
like
vs
code
or
IntelliJ.
But
then
there's
like
you,
know,
repel
it
in
a
bunch
of
different
tools
within
GitHub
gitlab.
Then
you
have
your
Source
control.
Whatever
you
choose
to
use,
gitlab
GitHub,
bitbucket
get
T
so
on
and
so
forth.
There's
deploy,
as
you
can
see.
We
have
Argo
and
Tech
time,
but
there's
other
tools
out.
There
are
a
large
list
of
tools
that
you
would
have
seen
in
the
previous
slide.
B
Packaging
and
storing
security
runtime
operate
so
runtime
kubernetes.
Maybe
you
want
to
deploy
serverless
shoes,
k-native,
Dapper
keita.
These
are
all
open
source
tools
by
the
way
or
open
source
Concepts
as
well.
Now.
This
is
all
a
lot
of
words
that
I'm
throwing
out
here.
What
the
is
all
this
mean.
Well,
when
we
talk
about
Cloud
native,
you
know
there
we
can
have
a
huge
long
definition
about
it,
but
the
way
I
always
see
it
is
it's
containerize
all
things
like?
Yes,
that
is
a
very
reductive
definition,
but
it's
an
app
definition.
B
You
know
another
containerized
platform
as
we're
starting
to
see
that
the
docker,
the
docker
oci
image
runtime,
is
a
very
popular
use
case.
So
there's
a
lot
of
different
ways:
you
can
use
it
so
when
we
talk
about
Cloud
native
CI
CD,
we're
essentially
using
containers
to
build
containers,
so
everything's
container.
B
And
so
yeah
we,
we
are
using
a
lot
of
the
containers
to
build
containers.
That's
what
you'll
see
with
like
Argo
and
techcon
as
we
dive
into
the
demo.
We,
the
different
steps,
actually
build
your
application,
our
containers
themselves
and
with
that
I'm
going
to
actually
turn
it
back
to
Muriel.
To
talk
a
little
bit
about
Argo.
C
So,
let's
get
into
our
go
and
we're
going
to
go
through
things
just
from
a
very
introductory
and
high
level
here,
but
the
best
place
to
start
is
actually
what
is
our
go
because
Argo
we're
focusing
today
specifically
on
the
Argo
CD
version,
but
the
Argo
project
itself
is
a
collection
of
Open
Source
tools
that
were
purpose-built
for
kubernetes,
for
everything,
from
running
workflows,
managing
clusters
and
so
on,
but
using
a
very
kubernetes-centric
point
of
view
and
that
a
little
bit
shortly
so
the
Argo
CD
portion
is
really
looking
at
this
declarative
get
Ops
model
for
continuous
delivery
within
kubernetes,
but
there
are
also
some
other
components,
such
as
workflows,
which
is
the
workflow
engine,
using
like
the
directed
graphs
and
step-based
workflows,
Argo
events
for
event-based
dependency
management
and
Argo
rollout.
C
So,
really
briefly,
a
little
bit
of
the
history
behind
Argo.
It
was
originally
developed
and
into
it
kind
of
by
way
of
a
startup
that
had
gotten
absorbed
So
within
Intuit.
This
project
had
started
officially
was
added
to
the
cncf
in
2020
and
graduated.
As
of
the
end
of
last
year,
in
December
I
got
several
contributors
on
GitHub
has
been
really
really
gaining.
C
A
lot
of
popularity
do
I,
in
my
opinion,
to
a
lot
of
this
very
kubernetes
Centric
approach,
so
that
you're,
using
the
same
and
similar
constructs
to
be
able
to
manage
your
applications
within
kubernetes
and
essentially,
when
we're
looking
at
these
kubernetes
native
tools.
It's
it's
using
that
same
camera,
the
kubernetes
resource
model
controllers,
custom
resources
and
so
on
and
a
little
bit
about
the
naming
history.
C
C
So
that
is
actually
a
photo
of
the
literal
Argonaut,
which
is
actually
also
an
octopus,
and
you
can
read
more
about
it.
It's
a
very
interesting
animal,
so
Argo
CD
is
mentioned,
will
focus
on
the
cd
part
of
this.
B
C
Pipeline
definition,
and
so
on,
so
this
creates
a
lot
of
the
ability
for
automation,
auditing.
You
have
the
single
source
of
Truth
for
your
configuration
and
then
also
even
from
a
resilience
point
of
view
when
you're
looking
at
being
able
to
restore
your
configurations
all
of
these
kind
of
live
in
this,
this
version
controlled
system.
So
you
do
have
your
backup
within
Source
control
and
also
you
have
the
ability
to
get
more
granular
as
far
as
your
actual
access
to
the
systems
themselves
for
your
roles
and
so
on,
determining
who
can
act?
C
C
And
if
we
page
on
and
I
guess
as
another
note
as
well,
this
allows
for
decoupling
from
your
CI
system,
so
within
workflows
and
everything
you
are
able
to
to
do
continuous
integration.
But,
for
example,
if
you've
got
a
team
and
you're
already
invested
in
things
like
Jenkins
or
you
have
things
to
do
your
build
systems
themselves.
These
can
remain
decoupled.
C
Where
now
you
have
a
tool
that
has
access
and
it's
set
up
within
your
cluster,
to
be
able
to
manage
your
actual
deployment
into
kubernetes
and
the
way
that
this
really
works
and
where
this
is
really
powerful.
Is
that
you
actually
now
don't
have
to
get
a
lot
of
these
creds
and
so
on,
set
up
and
secrets
access
to
your
cluster
and
everything
within
your
build
systems.
Your
build
systems
don't
need
to
have
that
connectivity
back
into
the
cluster,
which
now
creates
that
additional
level
of
security,
reducing
your
risk
footprint
with
Ergo.
C
You
now
have
the
server
components.
The
API
server
repository
server
application
controller
that
are
living
within
your
class
are
directly
within
your
cluster,
and
so
now
it's
doing
this
sort
of
outbound
pool
based
model,
and
it
makes
it
very
flexible
for
being
able
to
manage,
as
I
mentioned
your
your
security
and
if
we
go
on
to
the
next
slide
foreign.
C
C
You
can
have
that
entire
server
architecture,
as
shown
previously
deployed
within
your
application
cluster
and
deployed
directly
into
that
cluster
itself,
and
you
can
have
the
your
each
instance
separated
that
way
or
you
can
have
a
single,
maybe
a
main
instance
of
Argo
deployed
in
a
dedicated
cluster
and
then
your
various
other
clusters
that
are
being
managed
by
Argo
now
just
need
to
have
these
service
accounts
that
communicate
back
with
a
dedicated
cluster.
So
you
could
have
this
distributed
model
where
you
have
a
centralized
deployment
system.
C
That
now
is
able
to
manage
multiple
clusters
as
well.
So
you
have
a
few
of
these
installation
modes,
and
there
also
is:
there
are
various
Services
out
there
like
Acuity
and
so
on
that
do
offer
fully
managed
Argo
CDs
for
well,
so
that
now
it's
just
using
this
sort
of
agent-based
model
to
be
able
to
manage
your
infrastructure
and
we'll
go
into
a
little
bit
about
what
this
looks
like
in
the
demo
as
well.
C
So
I
think
we'll
go
back
one
I'm
a
little
bit
out
of
order
when
we're
looking
at
some
of
the
key
resources
that
you
use
to
be
able
to
Define
your
your
pipelines
within
Margo
there's
this
concept
of
an
application,
and
you
can
see
a
sample
of
that
on
the
right
and
this
application
is
essentially
an
instance
of
you
know
whatever
that
that
application,
or
that
that
business
application
is
it's
essentially
just
defining
the
git
source
and
the
destination
namespace.
C
C
Now
you
can
do
things
like
control
via
pull
request
and
get
access
who
can
deploy
to
certain
environments
and
so
on,
without
necessarily
having
to
configure
all
of
that.
Our
back
are
the
roles
and
permissions
within
your
kubernetes
cluster.
C
Then
we
also
have
the
idea
of
a
project
which
is
essentially
a
group
of
applications,
a
repository
which
is
now
the
The
Source
repository
as
you
can
see
here,
it's
just
using
a
GitHub
repo,
but
the
repository
and
the
credentials
are
defined
there
as
a
kubernetes
secret
and
then,
when
you're,
looking
at
the
Manifest
themselves
that
are
in
your
Source
repository
that
can
take
the
form
of
just
your
standard
yaml
or
you
can
use
things
like
customize
Helm
jsonnet
to
use
as
your
application
definitions.
C
All
right,
as
far
as
as
the
setup
goes,
it's
actually
pretty
quick
and
straightforward.
The
documentation
on
the
Argo
CD
site
is
really
right,
so
kudos
to
them.
But
essentially,
once
you
have
a
cluster
that
you'd
like
to
get
this
set
up
on,
then
it's
just
a
matter
of
creating
the
namespace
applying
the
the
yaml,
which
is
here
on
the
Argo
project,
GitHub
and
then
you're,
essentially
up
and
running.
You
can
pull
that
down
and
customize
it
or
if
you
wanted
to
version
lock
it
at
Pin
it.
C
All
right,
and
then,
as
far
as
using
Argo
and
we'll
really
dial
into
this
when
we
demo
there
are
kind
of
three
three
main
modes:
one
there's
an
Argo
CD
command
line
tool
that
allows
you
to
be
able
to
interact
with
the
Argo
CD
server
view
your
applications
lists
and
so
on,
which
is
really
flexible
for
being
able
to
do
just
some
scripting.
There
is
also
a
dashboard
that
is
built
in
so
once
you
get
that
Argo
server
deployed,
as
we
did
in
the
last
step.
C
It's
just
a
matter
of
exposing
either
through
you
know
some
type
of
Ingress
or
you
know,
port
forwarding
or
so
on,
but
that
dashboard
is
already
built
in
and
available
for
you
to
have
a
UI
based
method
of
interacting
with
the
server.
And
then
there
is
the
Argo
API
as
well
so
from
here
I
believe
we
will
hand
over
to
Jay
to
top
over
tecton.
B
Thank
you
very
much
so
yeah
we
talked
a
little
bit
about
Argo.
Now
we're
going
to
talk
about
techton.
These
two
are
not
necessarily
exclusive
from
each
other.
In
fact,
I
have
seen
a
lot
of
different
Industries
and
you'll
see
a
lot
of
examples
online
where
people
actually
use
them
together.
They
use
tecton
for
the
CI
portion
and
Argo
for
the
CD
portion
of
their
devops
pipeline.
So
let's
talk
a
little
bit
more
about
techton.
B
This
is
actually
a
pretty
famous
tweet
by
Kelsey
Hightower.
When
he
was
talking
about
kubernetes,
he
said
kubernetes
is
a
platform
for
building
platform.
It's
a
place
to
start,
not
the
end
game.
B
So
it's
not
the
idea
that
you
know
oh
I
have
kubernetes
and
it's
ready
to
be
deployed
and
all
my
applications
are
going
to
be
there
instead
think
of
it
as
the
building
blocks
to
build
the
platform
that
you
want
to
host
your
application
rather
than
starting
from
the
ground
up
and
using
you
know,
bare
metal
servers
and
trying
to
write
your
own
orchestration
tool
to
build
that
platform.
Another
way
to
think
of
it
is
if
you're
trying
to
build.
B
You
know
build
a
a
model,
a
house
or
something
like
that:
it'd
be
much
easier.
If
you
got
you
know
an
instruction
booklet
and
and
the
balsa
wood
and
stuff
versus
having
to
go
out
into
the
forest
and
cut
down
your
own
tree
and
you
know,
cut
down
the
lumber
in
order
to
make
the
sticks.
So
this
is
the
platform
for
building
platforms,
not
the
end
game.
In
the
very
same
way,
I
always
try
to
say
that
tecton
is
a
platform
for
building
your
devops
tool,
not
the
devops
tool
itself.
B
B
It's
called
declarative,
everything's,
enamel
and
there's
a
lot
of
different
benefits
to
it
that
we'll
dive
into
oh
and
even
dogs
love
it
so
have
a
little
tecton
cap
there
and
left
it
on
the
bed,
while
I
was
doing
something
and
she
decided
that
it
was
her
new
toy
and
I
think
she
is
right
now
building
a
pipeline
to
help
get
her
some
get
her
some
of
her
dog
food
into
the
bowl.
Without
me
there
now
one
thing
I
want
to
point
out.
Tecton
is
part
of
the
CD
Foundation.
B
Some
of
you
may
have
heard
of
it.
Some
of
you
have,
may
not.
You
can
think
of
it
as
a
sibling
Foundation
to
the
cncf,
so
both
are
kind
of
child
foundations
to
the
lynx
foundation,
so
they
work
together.
But
whereas
cncf
has
kind
of
a
larger
overarching
viewpoint
on
cloud
native
technology,
CD
Foundation
is
really
focused
on
on
continuous
delivery
and
continuous
delivery
exists
in
and
outside
of
the
cloud
it
can
exist.
On-Premise
it
can
exist
for
ML
Ops.
It
can
exist
for
data
pipelines
so
on
and
so
forth.
B
So
that's
why
people
decided
the
Linux
Foundation
decided
that
there's
a
benefit
of
having
a
separate
Foundation,
specifically
for
CD
and
tecton,
was
kind
of.
If
you
will
one
of
the
founding
products
around
it
in
the
same
way
that
you
can
say,
kubernetes
was
kind
of
the
Cornerstone
product
around
our
Cornerstone
project.
B
Around
cncf
techton
actually
used
to
be
a
part
of
k-native,
which
is
a
CN
CF
project
under
the
name
of
k-native
build,
but
eventually
the
the
creators-
and
this
is
kind
of
a
very
short
story
decided
that
you
know
there's
so
much
to
be
gained
from
what
k-native
build
was
becoming.
It
really
should
be
on
projects,
so
it
evolved
into
tecton.
As
we
see
it
today.
B
B
What
most
people
know
tecton
4
and
if
you
were
to
like,
say,
hey,
what's,
tecton
people
would
assume
pipelines
in
most
cases
and
that
wouldn't
be
wrong,
but
there's
also
a
dashboard,
a
CLI
tool
chains,
which
is
supposed
to
help
with
with
your
secure
software
delivery
triggers,
which
is
event
listening
so
automatically
trigger
if,
if
x,
event
takes
place
and,
of
course,
a
catalog
which
we
will
talk
briefly
about
later,
to
give
an
idea
of
what
tecton
pipelines
is,
which
is
part
of
what
we're
going
to
be
talking
about
pipeline
is
the
main
CI
CD
component
and
so
what
it
makes
up
a
pipeline.
B
So
you
have
a
step.
Each
step
is
like
the
individual
thing
that
happens
on
the
cic
workflow,
like
we're
on
a
pi
test
on
a
python
application,
pull
something
from
GitHub
push
to
a
kubernetes.
Cluster
task
is
a
collection
of
the
different
steps
that
are
initiated
in
a
single
pod.
So
you
know
a
pod
step
will
be
that
container,
that
executes
in
the
Pod
and
then
a
pipeline
is
a
collection
of
tasks.
B
One
way
to
look
at
it
is
so
here
you
have
the
pipeline,
and
this
is
the
entire
thing
like
I
want
to
take
my
code
from
GitHub.
Do
what
I
need
to
do
with
it?
You
know
test
it
containerize
it
push
it
to
my
kubernetes
cluster.
So
that's
the
overall
pipeline.
That's
the
thing
I
want
to
happen,
the
task
of
individual
items
that
take
place
or
the
individual
actions
that
take
place
that
each
represent
a
separate
kubernetes
pod.
So
you
have
a
task
for,
for
you
have
a
task
for
pulling
from
GitHub.
B
You
have
a
task
for
containerizing,
you
have
the
task
for
running
tests
and
then
each
task
is
a
different
step.
So
that
gives
you
a
kind
of
an
idea.
We're
going
to
also
talk
about
the
trigger
component,
which
is
for
Eventing.
So-
and
you
know
if
it's
just
me
working
on
a
personal
project
executing
the
runs
of
each
pipeline.
Isn't
that
big
of
a
deal
if
I'm
a
large
organization
I
want
some
automation
I
wanted
to
execute
based
on
XYZ
events,
so
we
have
what
we
call
the
trigger
the
the
trigger
component
for
tecton.
B
That
works
together
with
the
pipelines
so
you'll
have
an
event
listener,
which
is
a
crd
that
that
enables
a
declarative
way
to
collect
the
HTTP
events
with
Json
pay
loans.
Payloads.
There
is
now
a
new
protocol
called
CD
events
if
you're
at
all
familiar
with
Cloud
events,
it's
very
similar
so
trying
to
create
a
a,
not
a
different
type
of
protocol
for
cloud
communication,
a
different
type
of
protocol
for
CD
communication.
We
are
starting
to
see
a
lot
of
that
being
integrated,
now
trigger
template
or
resources
for
the
trigger.
B
So
excuse
me
for
the
item
here,
but
this
will
look
at
a
real
one
later,
but
this
kind
of
gives
you
an
idea
of
what
a
task
with
steps
look
like.
This
might
look
very
familiar
to
you.
It's
just
simple
yaml.
This
looks
very
similar
to
what
I
would
do
if
I
were
declaring
something
in
in
kubernetes
same
thing,
with
the
pipeline.
Very
simple,
I'm
declaring
all
the
different
steps,
the
different
tasks
that
are
supposed
to
execute
in
order
and
it's
pluggable
and
that's
one
of
the
big
things
too.
B
Each
one
of
these
tasks
that
make
up
a
pipeline
is
an
individual
component
and
it
can
just
be
moved
from
pipeline
to
pipeline
across
different
projects.
In
fact,
earlier
I
mentioned
this
catalog,
so
tecton
has
a
catalog
available
today.
That
is
a
bunch
of
reusable
and
tested,
so
there
have
been
testing
done
on
it
by
the
community.
So
there
is
some
you.
You
can
rely
on
using
them.
They're
they're
the
containers
that
are
their
tasks.
That
already
have
do
a
specific
item.
B
So
if
I
want
to
deploy
a
10
Canary,
if
I
want
to
do
a
canary
analysis,
if
I
want
to
deploy
to
kubernetes
pull
from
GitHub
instead
of
having
to
rewrite
those
tasks
from
scratch,
I
can
go
to
the
catalog,
pull
them
down.
They're,
probably
already
eighty
percent
of
the
way
there
I
tweak
it
with
my
specific
Branch
or
whatever
my
variables
or
specific
use
cases
are
and
boom.
B
It's
ready
to
go
so
now
we're
going
to
take
a
quick
moment
to
do
demos,
there's
two
demos
here,
one
for
tecton
and
one
for
Argo
in
the
interest
of
time,
because
we
do
want
to
give
you
a
chance
for
Tech
for
questions.
I
am
going
to
do
this
really
quickly,
so
bear
with
me
right
here
as
I
get
this
going.
B
To
do,
let's
see,
let's
just
do
a
window
here
all
right.
B
Let
me
expand
this
too,
so
this
is
Google
container
engine
or
Google.
It
used
to
be
called
container
engine
kubernetes
engine.
So
this
is,
you
know,
we're
googler,
so
we
use
it,
but
I
want
to
be
very
clear
that
this
will
work
on
any
kind
of
kubernetes
platform.
That's
not
just
limited
to
Google
any
kind
of
kubernetes
platform
will
work.
I
also
want
to
highlight
that
Google
is,
you
know,
very
committed
to
techton.
We
are
involved
in
its
development
and
our
you
know
we
we
want
to
see
it
succeed.
B
So
here
are
some
ideas
of
what
you
would
see
with
the
tecton
pipe
techton
pipeline.
All
these
are
actually
on
the
demos
too.
If
you
go
to
the
tecton
GitHub,
the
tecton
triggers
and
the
techton
pipelines,
you
can
find
a
lot
of
these
demos
as
well
and
play
with
them.
But,
as
you
can
see,
you
know,
this
is
just
a
kubernetes
object.
Called
a
pipeline
using
the
tecton
API
I
can
go
ahead
and
just
name
my
pipeline
put
a
namespace
I
set
parameters.
B
What
I
wanted
to
do,
where
it's
going
to
pull
from
all
that
good
stuff,
build
the
docker
image
so
right
here,
it's
going
to
deploy
something
called
event
display
and
it's
actually
going
to
build
that
Docker
image
using
canico
which,
if
you're
familiar
with
the
project,
it's
a
way
to
build
containers
in
your
kubernetes
cluster,
rather
than
having
to
like
pull
it
down
to
a
VM
and
execute
Docker,
build
or
or
whatever
build
tool
you
utilize,
and
then
it
deploys
it
as
a
pod.
B
So
here
are
all
the
different
steps
for
my
or
the
different
tasks
and
steps,
as
you
can
see.
So
if
we
actually
compose
that
or
decompose
it,
we
have
a
task
and
each
part
here
is
a
step.
So
this
is
actually
a
singular
step
task
where
it
runs.
Cube
CTL,
on
the
specific
item,
I
create
an
Ingress
there's
some
R
back
settings
that
you
can
set
up
that
you
will
find
in
the
documentation.
B
I
have
an
event
listener
here,
which
is
listening
for
my
GitHub
secret
I'm,
not
going
to
share
my
secret
on
a
YouTube
channel.
So
but
you
you
understand
the
concept
of
Secrets
and
it
will
then
be.
It
will
use
my
trigger
binding
here,
which
has
the
variables
for
the
GitHub,
your
URL
and
whatnot,
the
trigger
template,
which
declares
might
get
Hub
URLs,
and
everything
like
that
simple
enough
and
I
can
deploy.
So
this
will
just
this
kind
of
just
shows
you
the
benefits
or
how
it
works.
B
B
Namespace,
that
is
okay.
Well,
anyway,
you
gotta
love
live
demos
right,
so
what
would
what
it
would
do
is
display
if
I
execute?
Let
me
actually
go
ahead
and
display
the
dashboard,
and
that
way
you
can
actually
see
a
good
visualization
here.
So
bear
with
me
one
second,
because
I
did
deploy
that
dashboard.
B
Okay,
oh
that's
in
a
different
pod.
B
So
it's
like
changing
as
I.
Oh
here
we
go.
B
B
Use
the
tkn
CLI
if
I
prefer
to
live
in
the
CLI
in
my
dashboard.
That's
perfectly
fine,
but
I
also
have
the
this
nice
dashboard
if
I
don't
want
to
live
in
terminal,
so
I
have
both
options
available
in
the
interest
of
time
rather
than
having
people
watch
me
debug,
but
I
will
update
with
the
GitHub
to
show
you
what
I
have
deployed.
So
you
can
follow
along
I'm,
going
to
go
ahead
and
stop
sharing
and
give
Muriel
a
chance
to
show
her
Argo
CD.
C
So
I
do
have
a
combination
of
a
couple
things
that
we're
going
to
try
live,
but
then
also
we've
got
a
fallback
just
in
case
so
I'm
here,
essentially
in
in
my
workstation.
It's
sort
of
my
my
web-based
workstation
that
I
have
for
being
able
to
interact
with
our
Argo
cluster.
C
So
just
to
start,
essentially
when
we're
looking
at
the
configuration
that's
laid
out
or
the
simulation
is
that
I
have
one
of
my
main
clusters
here,
which
is
going
to
be
the
primary
cluster
running
those
Argo
CD
components,
and
then
also
we
have
two
application
clusters,
this
our
go
up
cluster
and
then
also
a
brand
new
cluster
that
we're
going
to
try
to
deploy
to.
C
So
if
we
wanted
to
take
a
look
right
now
at
some
of
the
workloads
that
are
running
within
the
Argo
cluster
itself,
I'm
going
to
pull
this
up
and
we
have
everything
here
in
the
Argo
CD
namespace
you
can
see,
we've
got
our
application
controller
application
sets
and
some
other
components
here
that
are
running
along
with
you
can
see
here.
This
guestbook,
UI
and
I'll
get
back
to
that
as
well
in
just
a
little
bit.
So
you
can
see
here
some
of
these
different
components
that
exist
within
the
Argo
World.
C
C
Now
we're
going
to
look
at
the
actual
applications
themselves,
so
you
can
see
we
have
this
very
kubernetes
Centric
method
of
being
able
to
interact
with
the
Argo
CD
server.
So
if
you
wanted
to
use
a
lot
of
these
native
commands,
you
are
able
to
do
that.
We
have
the
boutique
and
this
you
can
see
even
the
health
status.
C
This
one
is
degraded,
but
we
have
these
other
two
that
are
synced
and
healthy,
and
if
we
wanted
to
go
in
and
describe
this
application
that
has
been
set
up,
you
can
see
that
now
you
have
very
similar
definitions
to
the
ones
that
you
would
use
for
being
able
to
manage
your
actual
deployments
and
so
on
of
your
application
logic.
So
you
can
actually,
even
you
know,
use
Argo
to
manage
Argo,
since
we
have
all
of
these
same
constructs.
So
it's
kind
of
this
infinite
Loop
yeah.
So
to
speak.
C
So
now
we
are
going
to
attempt
to
add
this
new
cluster,
as
I
mentioned
we
have
actually
so
here.
Let
me
go
back
into
Argo
CD.
You
have
your
command
line
tool
and
if
we
wanted
to
see
some
of
the
different
commands
here
that
are
available
for
Argo
CD,
you've
got
a
lot
of
these
things
that
are
available
to
be
able
to
manage
your
actual
interact
with
a
server
so
I've
already
logged
into
this
server
that
I
have
set
up.
C
So
if
I
wanted
to
do
say,
Argo
CE
apples,
then
you
can
see
a
list
of
the
applications
here.
It's
similar
to
that
are
this
requester
list.
So
you
can
see
that
I
have
two
clusters
that
are
set
up
right
now,
the
native
which
is
in
cluster.
So
it's
the
actual
cluster
that
cargo
is
deployed
to,
and
then
this
other
remote
cluster,
so
to
speak,
the
Argo
app
cluster.
C
So
you
could
just
essentially
build
out
a
collection
of
all
of
the
different
clusters
that
have
been
set
up
to
be
managed
by
Argo.
So
now
we're
going
to
attempt
to
add
that
new
cluster
in
which
is
that
cluster
that
I've
just
created
so
to
be
able
to
do
that.
And,
of
course,
this
is
just
one
method
of
being
able
to
interact
with
Argo
CD,
which
is
this
a
little
bit
more
of
like
command-based.
C
Essentially,
what
this
would
look
like
as
you're
running
in
production
is,
you
would
have
various
yamls
and
configuration
configurations
defining
a
code
and
we'll
look
at
that
in
a
moment.
But
if
we
did
want
to
add
in
that
new
cluster,
we
would
do
a
new
cluster,
and
essentially
you
can
see,
we've
just
got
some
service
accounts
and
roles,
and
so
on
that
are
being
created
in
the
new
cluster,
and
now
this
has
been
added
in.
C
So
if
we
wanted
to
be
able
to
create
an
app
via
the
command
line,
and
actually
let
me
update
it-
it's
here
destination
server
and
we're
just
going
to
deploy
into
the
default
namespace
just
keeping
this
really
basic.
For
now,
there
are
actually
various
sample
applications
that
are
available
on
the
Argo
project
site.
C
So
I'm
gonna-
hopefully
it's
showing
up
on
a
page
over
here
to
how
about
when
we
look
at
these
example
apps,
because
each
of
these
folders
is
set
up
with
the
actual
yaml
and
deployments
and
so
on,
and
some
of
them
with
Helm
and
customize.
Essentially,
all
you
really
need
to
do.
I
don't
have
pulled
or
push
access
or
anything
to
this,
this
repository
itself,
but
because
those
yamls
are
there.
I
can
just
point
to
that
folder
and
path
as
the
source
for
the
actual
application,
Define
women
or
go
here
what
the
destination
server
is.
C
We
have
the
path
we
have
this
destination
server,
the
destination
namespace,
which
by
default
the
name
space-
should
already
exist,
but
there
are
also
a
variety
of
different
flags
and
options.
If
you
wanted
to
have
it
auto-generate
the
namespace
for
you
and
we
can
just
go
ahead
and
try
to
create
that.
So
let's
do
this.
C
And
so
now
we've
got
this
application.
Helm
desk
book
created,
so
oh
actually,
I
I
did
not
go
into
the
application
tile.
So
you
can
see.
Oh
so
it
just
showed
up
this
Helm
guest
book.
So
these
this
is
the
actual
Argo
CD
application
interface
or
the
the
dashboard
I
have
a
few
applications
that
I
have
created
previously
I've
got
this
remote
guest
book.
This
guestbook
and
cluster,
and
you
can
see
here-
is
the
brand
new
Helm
guest
book
that
I
just
created.
So
it's
missing
and
out
of
sync.
C
So
what
I'm
going
to
go
ahead
and
do
is
set
up
a
sink,
and
this
sink
can
also
so
basically
I'm,
essentially
synchronizing
the
Manifest
into
the
repository
I'm
set
up
right
now
by
default
just
to
do
manual,
but
of
course
this
can
be
set
up
to
sync
at
an
automated
basis
so
that
it's
just
pulling
the
repo
for
any
changes
that
might
be
happening
again.
C
This
is
very
much
centered
on
that
deployment
side
of
things
where
a
lot
of
the
CI
is
going
to
be
happening
and
the
the
CI
and
the
builds
and
so
on
are
going
to
be
happening
before
this
point.
So
it's
mostly
once
that
manifest
lens
in
that
destination
directory.
But
now
you
can
see
this
is
healthy.
It's
synced!
C
We
have
a
few
different
views
here
in
this
dashboard,
as
I
mentioned
this
ships
out
of
the
box
with
Argo,
when
you
do
your
Baseline
installation
and
you
can
see
for
each
of
these
there's
a
source,
a
destination
and
when
you're
looking
at
being
able
to
do
just
multi-cluster
management,
that's
where
things
like
having
customized
and
having
some
of
these
other
templating
structures
put
into
place
to
manage
your
say:
Dev
and
production
and
staging
environments
or
multiple
cluster
footprints
that
are
distributed
as
well.
So
you
have
a
few
different
views
here.
C
You
have
this
sort
of
project
View,
and
then
you
also
have
a
little
bit
of
a
high
level
view
if
we
wanted
to
say
what's
in
sync:
what's
out
of
sync:
what's
healthy
and
what's
not
healthy,
and
you
can
see
here
with
this
Boutique
application,
you
know
I
actually
hadn't
intended
for
it
to
be
in
a
healthy
State
when
I
first
deployed
it.
C
It
was
more
of
my
cluster
sizing
issue,
but
it
actually
is
really
helpful
for
demonstration
purposes,
because
now
you
can
see
how
Argo
CD,
having
this
very
kubernetes,
Centric
and
integrated
point
of
view.
You
can
actually
get
visibility
into
the
system
using
the
same
type
of
constructs
and
objects
that
you
would
be
accustomed
to.
So
you
can
see
here
we
have
this
deployment
status.
We
can
see
the
application,
health
and
so
on,
and
then
we
can
actually
also
see
where
we
have
some
services
that
are
actually
experiencing
issues.
C
So
if
we
wanted
to
go
in
here
and
actually
see
some
events
and
logs
and
so
on,
then
we're
able
to
do
that
as
well.
So
let
me
actually
just
pop
over
here
and
I'm
gonna
wrap
this
up
soon,
just
because
I
know
we
wanted
to
save
five
minutes
or
so
for
questions.
But
I
will
go
back
in
here
to
my
workloads,
I
see
I'll
get
my
ad
Services
broken
something
that
you
know
you
wouldn't.
C
Or
another
environment
I'm
like
let
me
just
delete
this
see
what
will
happen
so
I'm
going
to
delete
this
we'll
come
back
to
this
one
in
just
a
second,
but
what
I
also
wanted
to
show,
so
those
were
a
few
methods
of
being
able
to
add
to
add
an
application.
C
Of
course,
you
are
also
able
to
add
an
application
here
through
the
UI
where
you
go
in
and
you
can
create
a
another
app
another
guest
book
so
on,
but
one
thing
that
I
the
project
name
and
so
on,
and
one
thing
that
is
also
great
about
being
able
to
add
this
through
the
dashboard.
C
Is
you
have
the
native
ability
to
be
able
to
also
see
the
ammo
that's
being
created
so
even
though
you're
using
the
UI
based
method,
you
can
also
now
have
this
as
a
reference
for
the
future,
so
say
say
you
wanted
to
say.
Well
let
me
let
me
go
through
the
UI
for
the
first
time,
I'm,
not
sure
of
all
of
the
different
parameters
and
so
on.
You
can
build
this
out.
C
Have
the
yaml
use
that
as
a
template
for
the
future,
and
of
course
this
is
going
to
be
now
part
of
that
crd
and
that
actual
definition
within
kubernetes,
so
you
can
always
output
that
as
well.
C
So
that's
all
one
piece
and
then
the
final
is
looking
at
this
other
method
of
of
now.
Actually
we're
going
to
look
at
the
new
one
now
being
able
to
have
this
definition
for
that
pipeline.
We
just
saw
that
within
the
UI,
but
now
I
have
this
here
for
an
application
that
we
are
going
to
be
deploying
into
this
new
cluster.
So
this
is
that
new
cluster
that
we
had
just
that
was
was
sort
of
like
newly
added
into
Argo.
C
Cd
I've
got
this
in
the
repository
you
know,
we've
got
some
information
like
the
namespace
and
the
server
The
Source
and
the
target
revision.
That's
actually
the
branch
that
I'm
going
to
be
using
because
I
I
want
to
have
this
just
pull
off
of
a
specific
Branch.
You
can
have
some
other
parameters
as
well
and
essentially
now
what
I'm
going
to
do
is
we'll
take
that
yaml
and
say
I'm
gonna
make
sure
that
I'm
using
the
Argo
cluster
and
we're
pulling
into
that
namespace.
C
And
now
I'm
just
going
to
apply
this,
you
know
much
like
I.
Would
you
know
another
deployment
and
so
on?
C
And
so
now,
okay,
you
can
see
that
I've
created
this
new
application
and
if
I
go
back
in
here.
C
So
if
I
go
back
in
here
and
click
that
a
little
bit
too
quickly,
but
you
can
see
we
have
this
new
Boutique
prod
configuration
that
was
just
applied,
so
I'm
gonna,
just
synchronize
all
of
these
manually
once
again
and
as
you
can
see,
this
Boutique
application
is
syncing
once
more
and
actually,
if
I
go
back
here
and
refresh
for
that
cluster,
essentially
what
should
happen
is
those
two
deployments
that
I
just
deleted
are
now
back
again
because
it's
taking
that
default,
yaml
and
saying
okay
I'm
going
to
sync.
C
So
even
though
I
went
in
here
and
deleted
it,
it's
using
that
repos
the
source
of
Truth
to
deploy
it
again
and
right
now,
essentially,
I
can
go
and
debug
the
switch.
It
just
needs
more
resources
on
the
cluster
so
that
that
was
just
kind
of
very
quick
demo
at
looking
at
some
ways
of
being
able
to
interact
with
Argo
CD
and
how
that
really
looks
into
Loops
into
the
kubernetes
point.
Centric
point
of
view
so
I
think
from
here
I
guess.
Maybe
we
can
open
it
up
for
any
questions.
A
B
So
for
containerization
I
believe
we
can
just
use
whatever.
So
if
you
want
to
use
dock
or
if
you
want
to
use
pod
man,
if
you
want
to
use
anything
like
that,
as
long
as
it
creates
like
the
the
an
oci
image
pulse,
I,
don't
see
I
image
standard
for
the
wrong
time,
then
you're,
fine,
I,
personally
use
pod
men
on
my
machine,
so
I,
don't
think
I'm,
not
sure.
If
that
answers
your
question,
but
you
can
use
anything.
B
A
All
right,
okay:
this
is
a
long
one
get
ready.
Okay,
I
have
implemented
CI
CD
using
tecton
and
Argo
CD,
while
creating
a
pipeline
where
I
am
working
right
now.
What
I've
noted
is
that
it
takes
more
time
while
Building
images
from
Docker
files,
specifically
JavaScript
paste,
front-end
application
than
any
other
tool
when
compared
to
techton.
Is
there
any
recommendation
on
how
it
can
be
improved,
I'm
using
conico
for
building
image?
Secondly,
while
running
pipeline,
it
takes
a
huge
amount
of
underlying
node
disk
space
while
checking
it
with
Prometheus
and
grafana.
A
C
A
C
You
know
images
that
you're
building
that
are
using
roughly
the
same
stack
and
framework
and
so
on,
and
if
those
are
building
a
lot
faster,
then
I
think
maybe
dialing
back
and
going
kind
of
in
the
stepwise
manner
to
look
at
like.
Maybe
there
are
some
dependencies
or
something
like
that
that
are
creating
this
really
huge
footprint,
so
I
think
it's
mostly
looking
at
how
to
be
able
to
optimize
and
build
like
a
slightly
leaner
image.
C
I
know
that
I
I
don't
have
it
handy,
but
I
think
there
are
some
Guides
Online
that
talk
about
how
to
be
able
to
streamline,
streamline
your
builds
and
streamline
your
images,
maybe
looking
at
the
base
images
themselves.
So
there
may
be
a
few
different
things
that
you
can
do
for
looking
at
optimizing
that
build
back
portion
of
the
build
itself,
because
I
think
that
might
address
both
of
those
is
that
maybe
there
are
some
things
that
are
happening
in
the
background
or
some
dependencies
that
aren't
necessary
for
that
actual
application
like.
A
A
B
Cool
yeah,
you
can
usually
somehow
link
the
final
step
of
a
trigger
or
of
a
pipeline
to
trigger
the
first
step
of
another
Pipeline,
and
you
can
usually
use
event
binding
or
there's
a
lot
of
different
ways.
You
can
execute
it,
but
it
is
doable
and
there
are.
There
are
some
demos
like
in
the
tecton
community,
specifically
on
that
use
case.
A
All
right:
well,
we
are
at
time
I
know
there
were
a
couple.
Other
questions
left
if
Mariel
and
Jason
want
to
pop
their
handles
into
the
chat,
then
maybe
y'all
can
follow
up
with
them
after
the
show.
But
thank
you
everyone
for
joining
us
today.
Thank
you,
Jason
and
Muriel
for
an
awesome
presentation,
lots
of
great
interaction
and
conversation
and
I'll
leave
this
up
for
just
a
minute,
while
everybody
logs
out
so
that
y'all
can
be
sure
to
get
their
info
and
follow
up
with
them.