►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Modern CI/CD with Tekton and Prow Automated via Jenkins X - James Rawlings, Cloudbees & Christie Wilson, Google
There’s been lots of innovation in the CI/CD space around the Kubernetes ecosystem, with the introduction of Tekton (formerly Knative) Pipeline and it's deep integration with Prow from the Kubernetes testing sig. This session will show you how to get started with Pipeline on your own clusters for your CI/CD needs, leveraging Prow for webhooks and powerful ChatOps capabilities on pull requests and issues. The live demo will also show we can use Jenkins X to orchestrate and automate building applications leveraging both Pipeline and Prow, so that we can all benefit from the awesome innovation.
https://sched.co/MPZ4
A
Many
of
you
have
been
to
more
than
one
cube
con
before
before
this
okay
cool
and
how
many
RPF,
but
to
keep
calm
for
a
first
time
right
like
most
of
you
well
welcome,
welcome
to
keep
calm
and
I
mean
it's.
It's
wrapping
up
pretty
much
right,
I
hope
you
had
a
great
couple
days
here
in
Barcelona,
it's
sunny,
I,
hope,
you'll
still
catch
some
of
that
Sun
before
you
go
home
and
well.
The
next
talk
is
going
to
be
by
James,
routing
and
Christie
Wilson.
They
can
talk
about
using
prowl
and
Tecton.
A
B
C
D
C
D
C
C
So
this
is
we
james
rawlings
on
on
the
left
of
people
in
the
back.
My
by
the
way,
there
is
a
lot
of
you
out
there
I'm
trying
not
to
look
out
there
with
quite
as
far
so
I'm
the
one
on
the
left,
I
work
for
cloudBees
I
work
on
an
open
source
project
called
chickees
X
and
we
are
I've,
been
working.
The
last
couple
of
years
trying
to
help
other
developers
go
faster.
D
Hi
everybody
I'm
Christie
Wilson
I'm,
a
software
engineer
at
Google
I
throughout
the
years
I've
worked
in
a
lot
of
different
industries.
I
work
in
mobile
I've
worked
in
foreign
currency
exchange,
I've
even
worked
in
triple-a
games,
but
don't
matter
what
in
industry
I
go
to
I,
always
end
up
gravitating
towards
work,
that's
related
to
see
ICD
and
testing
and
I'm
really
passionate
about
it.
So
these
days,
I'm
really
excited
to
be
leading
the
Tecton
project.
C
D
So,
let's
start
with
a
bit
of
time,
travel
and
look
at
the
history
of
tech
time,
so
we're
gonna
go
all
the
way
back
to
2018
when
the
K
native
project
started.
So
the
K
native
serving
project
in
particular,
is
all
about
an
open
source
solution
for
serverless
on
kubernetes.
So
in
order
to
do
that,
they
needed
a
way
to
go
from
source
code
to
deployments
and
to
build
images
in
kubernetes.
D
So
that's
what
Kay
native
build
was
all
about,
and
people
got
really
excited
just
about
being
able
to
build
images
on
kubernetes
and
then
they
quickly
wanted
more.
They
wanted
to
run
tests
before
they
did
the
builds
and
they
wanted
to
create
more
complicated
pipelines.
So
we
created
the
K
native,
build
pipelines
project
and
then,
as
the
scope
of
that
increased,
we
moved
it
into
its
own
org
called
Tecton,
and
that's
where
tech
tongs
and
Tecton
came
from
so
Tecton
is
all
about
creating
a
spec
for
CI
CD
that
can
be
shared
among
vendors.
D
So
we've
taken
a
lot
of
the
stuff
that
we've
been
doing
with
CI
CD
for
years,
and
we've
made
a
declarative,
typed
model.
On
top
of
it,
that's
all
built
around
containers
and
we've
made
it
decoupled.
So
the
idea
is
that
you
should
be
able
to
start
on
a
brand
new
project
in
a
brand
new
repo
and
take
that
entire
pipeline
and
run
it
against
your
own
infrastructure
or
take
pieces
of
that
pipeline
and
run
them
on
their
own
or
even
reuse
them
in
your
own
pipelines.
D
So
we
started
out
with
just
pipelines
and
pipelines
are
still
at
the
core,
but
now
we
have
other
projects
too,
like
we
have
the
CL
I
project
and
the
dashboard
project
and
we're
incubating
some
event
triggering
projects
as
well,
and
we're
doing
this
with
a
lot
of
folks.
So
we
currently
have
regular
contributors
from
cloudBees
from
Red
Hat
from
IBM
and
Salesforce,
and
if
you're
interested
in
joining
us,
we've
put
a
lot
of
work
into
trying
to
make
it
really
easy
to
ramp
up
and
get
started.
So
please
join
us.
D
C
So,
let's
actually
start
a
little
bit
further
back.
Let's
start
in
2004
when
Hudson
was
created,
which
evolved
into
Jenkins
by
Koski
Jenkins
as
a
CI
server
has
had
phenomena
phenomenal
success
as
an
open-source
project.
It's
really
quite
outstanding,
some
of
the
numbers
that
we
that
we
know
and
how
that
open-source
community
has
grown.
There
are
thousands
there's
over.
C
A
thousand
plugins
have
been
created
being
contributed
and
there
is,
as
we
know,
200,000
installations
running
Jenkins
server
is
running,
but
actually
those
the
only
ones
we
know
about
it
actually
predicted
to
be
closer
to
a
million.
There
are
15
million
Jenkins
users
out
there,
which
really
is
quite
astonishing,
and
we,
you
know
a
congratulations
to
the
open
source
community.
This
help
evolved
that
and
I
said
that
was
in
2004
when
some
of
these
things
started
and
it's
evolved
over
time,
and
but
there
are
some
kind
of
challenges
from
present
day.
C
There
is
a
single
point
of
failure
at
the
moment.
So,
if
you're
performing
any
maintenance,
if
you're
installing
a
plug-in
or
you've,
got
some
downtime,
then
actually
going
to
miss
any
webhook
triggers
you
miss
builds,
which
is
a
missed
appointments
as
well
also
down
to
some
of
those
successes
around
one
plug-in
model,
and
what
actually
happens
is
the
cloak
is
get
installed
into
the
JVM
on
to
Jenkins
server.
And
you
can
you
know,
there's
a
thousand
plugins
have
been
created.
C
That
also
means
you
can
install
thousand
plugins
into
your
Jenkins
server,
which
could
be
bring
to
instability
and
large
JV.
Yet
because
it's
a
JVM,
large
resource
usage
as
well,
and
when
we're
considering
them
about
the
cloud
actually
that
you're
starting
to
pay
for
that
as
well
and
also
there's
some
challenges
around
scaling
with
jobs,
because
when
in
Jenkins
you
actually
run
a
job,
you
actually
gets
executed
on
the
Jenkins
server.
So
you
can
have
this
kind
of
noisy
neighbor
effect
where
other
teams
within
your
organization,
so
that
could
commit
a
bad
pipeline.
C
It
could
actually
have
a
bad
effect
on
your
own
teams
as
well.
But,
with
you
know
the
advancements
of
Technology
containerization,
the
cloud.
It's
a
thing.
We're
really
trying
to
start
looking
at
how
we
can
start
to
leverage
more
of
these
concepts
and
leveraging
more
of
the
clouds
deep
pushing
down
into
the
platform.
More
so
Jenkins
X
is
aiming
to
become
a
developer
experience
around
kubernetes.
It
isn't
that
easy
to
get
started.
C
We
recognize
that
we
want
to
help
all
those
15
million
Jenkins
users
and
everybody
else
in
the
world
helped
move
them
the
clouds
making
it
super
easy
and
continually
delivering
ourselves
with
Jenkin
sex.
You
can
create
new
applications.
You
can
import
existing
applications
as
well
on
into
kubernetes,
and
we
set
up
all
this
CI
CD
as
well.
All
the
web
hooks
and
everything
we
actually
add
in
everything.
That's
needed
to
be
able
to
build,
deploy,
package
and
run
that
application
as
well
in
kubernetes,
it's
not
just
for
kubernetes
as
well.
C
You
could
invent
other
traditional
workloads
as
well
that
you
went
with
Jenkins
servers,
also
what
we
try
and
do
as
well
and
everybody
here
read
the
accelerate
book,
a
few
people
more
people
need
to
read
it.
They
absolutely
do
it's
a
phenomenal
book.
I,
really
recommend
it.
What
jenkins
x,
where
we
can
we've
tried
to
take
capabilities
recommended
by
accelerates,
so
that
we
can
have
higher
performing
teams,
and
this
is
just
some,
but
obviously
I
would
really
recommend
going
the
reader.
It
really
kind
of
changed.
C
My
life
I'd,
say:
okay,
jenkins
x
as
well,
so
we
have
the
concept
of
environments,
so
this
is
kind
of
new.
From
from
traditional
jenkins
we've
taken
an
extending
kubernetes
and
the
way
it's
meant
to
be
extended,
so
we're
going
to
hear
a
little
bit
more
about
c
RDS
from
christie
shortly,
but
just
to
keep
that
in
mind,
we
are
really
embracing
this
new
architecture
as
well
and
like
the
plug-in
model
we
have,
we
exist
in
plug-in
model.
C
We
actually
want
to
promote
micro
services,
a
dream
to
event-driven
architectures
as
well,
so
that
we
can
actually
scale
those
those
plugins
as
well
and
also
one
really
really
exciting
things
is.
We
can
support
pluggable
pipeline
execution
engines,
which
kind
of
then
really
leads
us
to
detect
on
just
one
quick
slide
on
this
on
this
journey
with
Jenkins
XO,
we
actually
started
with
Jenkins
X,
starting
up
a
Jenkins
server,
all
the
time.
C
Having
it
running
all
the
time
locally,
but
obviously
we're
running
this
on
on
kubernetes
and
we're
getting
charged
for
when
builds,
aren't
being
run,
then
we
looked
at
using
proud
quite
a
few
people
where
their
hands
up
gonna
have
a
little
bit
more
about
price
shortly,
but
we
were
able
to
orchestrate
and
spin
up
using
prowl
and
one-shot
Jenkins
server
run
the
pipeline
and
throw
it
away
afterwards.
But
then,
luckily,
we're
still
using
a
JVM
here,
we're
using
a
JVM
inside
the
cake
container
to
run
our
run.
C
Our
builds
so
high
resource
usage
and
we
actually
have
running
into
some
memory
issues
and
various
other
things
so
like
a
gift
from
from
above.
After
that,
Tecton
pipelines
came
along
and
we've
completely
embraced
it
and
we're
really
thankful
to
hear
more
about
it
from
Christy
as
well
and
just
one
last
thing.
C
D
So
the
first
thing
to
understand
is
that
Tecton
pipelines
is
built
using
crts,
so
how
many
people
have
heard
of
CR
DS?
That's
it's
a
lot.
How
many
people
are
actually
using
CR
DS
in
production,
yeah,
fair
number,
so
if
you're
not
familiar
with
them
or
if
you've
only
just
heard
of
them,
it
stands
for
custom
resource
definition
and
it's
a
way
of
extending
kubernetes
itself.
D
So
there's
the
ones
that
are
based
on
client
go
which
are
all
about
statically
generated
files,
and
whenever
you
change
your
CID
definitions,
you
have
to
regenerate
the
code,
that's
used
to
interact
with
them,
and
then
there
are
the
ones
based
on
the
controller
runtime,
which
are
more
dynamic
and
use
reflection
to
actually
inspect
your
types
and
see
what
their
structure
are.
What,
while
you're
running
and
for
for
Tecton
pipelines,
we're
using
K
native
pkg,
because
we
started
out
in
the
K
native
project
and
because
it
actually
works
pretty
well.
D
So
let's
talk
about
how
Tecton
pipelines
works
and
what
CRTs
we
created
for
it.
So
the
most
basic
building
block
is
something
that
we
call
a
step.
So
a
step
is
actually
an
instance
of
an
image
and
it's
a
kubernetes
container
spec,
which
is
something
that
already
exists
in
kubernetes.
So
this
is
an
image
with
everything
that
you
need
to
run
it
like
the
arguments
and
the
environment
variables,
the
first
new
type
that
we
added
is
called
a
task.
D
The
next
new
type
is
called
a
pipeline
and
a
pipeline
lets
you
put
together
tasks,
so
they
can
be
run
concurrently,
they
can
be
run
sequentially
or
you
can
create
really
complicated
graphs.
They
are
not
guaranteed
to
execute
on
the
same
node,
but
you
can
actually
have
inputs
from
one
task
that
come
from
the
output
of
another
task,
which
are
specified
in
the
pipeline,
so
pipelines
and
tasks
are
declared
once
and
they're
used
again
and
again
to
actually
invoke
them.
D
You
create
pipeline,
runs
and
task
runs,
which
invoke
pipelines
and
tasks,
and
then
our
final
new
type
is
called
a
pipeline
resource
which
provides
runtime
information
to
those
runs.
So
this
is
for
things
like
what
image
registry
should
I
be
uploading
to
what
git,
repository
or
fork
should
I
be
executing
against.
D
D
D
Okay,
so
let's
talk
about
some
of
the
challenges
that
we've
run
into
with
kubernetes,
to
make
this
work
I'm
going
to
talk
about
three
different
challenges,
so
the
first
one
is
about
running
steps
in
order,
so
you
may
remember:
a
task
runs
a
series
of
steps.
They
execute
an
order.
Each
one
of
those
is
a
container
that
runs
and
then
finishes.
It
turns
out
that
there
isn't
really
a
very
good
way
in
kubernetes
to
declare
that
you
want
a
container
a
series
of
containers
to
run
until
completion
on
the
same
node.
D
So
the
solution
that
we
have
to
this
is
very
interesting
by
which
I
mean
it's
it's
hacky,
but
it
works.
So
what
we
do
is
we
put
all
of
the
containers
for
your
task
into
the
same
pod
and
then,
when
you
declare
these
steps,
you
specify
a
command
to
run.
You
either
do
it
explicitly
or
it's
in
the
definition
of
the
container
itself.
D
So
what
we
do
is
we
go
and
look
up
that
command
and
we
find
it
and
then
we
put
our
own
binary
into
your
container,
which
is
executed
instead
and
then
our
binary
waits
until
your
container
is
supposed
to
actually
execute
and
then
execute
the
binary.
So
all
the
containers
are
actually
running
but
they're
all
waiting
for
their
turn
to
run
and
signaling
to
each
other
when
they're
done.
D
The
next
interesting
challenge
is
one
that
I
want
to
give
complete
credit
to
Alex
to
Carlo
for
it,
because
we
did
not
realize
that
we
were
going
to
run
into
this
at
all
and
he
went
and
did
the
investigation
found
the
problem
reported
it
and
then
is
currently
working
on
a
solution.
So
all
the
credit
goes
to
him
for
this,
but
it's
very
interesting.
We
had
been
thinking
about
using
sidecars
for
some
of
our
first
to
solve
some
of
our
problems.
We
didn't
realize
that
they
actually
don't
really
just
work
out
of
the
box.
D
The
way
you
might
expect
so
two
specific
problems,
a
side
car
is
it's
like
a
supporting
container
that
you
would
run
alongside
your
containers.
So
this
is
how
systems
like
sto
do
things
like
providing
proxies
for
your
containers,
so
you're
trying
to
run
something,
and
this
other
container
that's
also
running
and
doing
some
work
for
you.
So
the
specific
problems
we
ran
into
are
we
we
don't
want
to.
If
we
have
side
cars,
we
don't
want
our
steps
to
actually
start
until
the
side.
D
Cars
are
ready,
so
they
need
to
wait,
and
the
other
problem
is
that
as
far
as
kubernetes
is
concerned,
if
anything
is
running
in
your
pot
at
all,
your
pot
is
still
running
and
we
actually
want
to
run
steps
until
completion.
So
if
the
side
car
keeps
running,
kubernetes
thinks
that
the
pot
is
still
up
and
leaves
it
so.
D
The
solutions
that
we're
looking
at
right
now
are
we're
going
to
use
something
called
the
downward
API
so
that
we
can
tell
when
the
side
cars
are
actually
executing
and
when
the
steps
should
run
so
we're
taking
advantage
of
that
hacky
binary
that
we
put
inside
our
container
and
then
that
is
checking
the
downward
API
to
see
when
the
side
cars
are
ready
and
then
actually
executing.
You
can
look
at
more
on
the
downward
API.
D
If
you
want
it's
basically
a
way
for
a
container
to
inspect
the
state
of
the
kubernetes
cluster
without
having
to
make
a
request
to
the
API
server
and
then
to
stop
the
pods.
When
the
steps
finish
we're
going
to
do
something
equally
hacky
and
actually
change
the
pod
spec
replace
the
sidecar
container,
with
a
no
op
container
that
completes
immediately.
D
And
then
the
last
issue
that
I
want
to
talk
about
is
about
the
outputs
and
inputs.
So
I
mentioned
the
in
a
pipeline.
You
can
take
the
outputs
of
one
task
and
provide
them
as
inputs
to
another,
so
this
basically
means
you're
taking
some
binary
data
that
was
produced
by
one
set
of
containers
on
on
one
node
and
you're,
providing
it
to
a
different
node.
So
we
have
a
couple
ways
that
we've
made
this
work.
D
We
have
two
that
we've
actually
implemented
in
a
third
one,
that
we're
kind
of
theoretically
exploring
and
we're
also
very
open
to
other
solutions.
If
you
have
one
so
the
first
one
is
that
we
create
something
called
a
persistent
volume
claim
and
our
PV
C,
and
we
attach
it
to
your
running
pods
when
they're
running.
So
if
we,
if
we
detect
that
you
have
linked
outputs
and
inputs,
we
create
this
volume
and
then
your
tasks,
steps
can
write
to
the
volume
and
then
the
volume
is
provided
to
any
downstream
tasks
that
need
to
consume
it.
D
So
it
turns
out
this
isn't
great,
though,
because
not
all
clouds
support
PVCs
in
the
same
way
and
also
it's
very
slow
to
create
and
attach
these
PVCs,
so
an
alt,
an
alternate
method
of
doing
this
that
we
created
it
involves
doing
kind
of
the
same
thing,
but
you're
uploading
to
blob
storage
in
between
tasks,
and
it
turns
out
that
this
is
also
quite
slow.
So
the
theoretical
solution
that
we're
exploring
is
maybe,
in
this
case
we
figure
out
in
advance
that
you're
trying
to
do
this,
and
we
actually
do
schedule
onto
the
same
note.
D
C
So
if
you
haven't
guessed
it
yet,
Jamie's
ex
loves
Tecton
pipelines
really
to
encourage
everybody
to
be
looking
at
this
we've
gone
all-in
on
Tecton
ourselves.
We
actually
dog
food
Jenkins
out,
so
we
build
Jiang
his
ex
with
Jenkins
X
and
we've
moved
all
of
our
own
repositories.
I
think
there's
maybe
about
60
70,
80
repos
they're
now
using
Tecton
pipelines.
C
That's
given
this
huge
improvements
in
performance,
reliability
and
stability
and
also
reduce
our
costs
as
well,
because
this
just
to
be
clear,
there's
no
JVM!
Here
at
all.
We
are
just
running
engine
taka
containers
running
our
commands
running
our
steps,
so
we
also
have
a
user
project
called
prowl.
Prowl
is
an
open
source
project
used
on
the
kubernetes
on
every
single
kubernetes
repository
out.
There
also
used
by
other
projects
as
well
comes
from
the
testing
the
tests
infer,
git
repository.
C
It
allows
us
it
does
many
things
actually,
where
it's
the
TLDR
would
be
a
helps
us
handle
webhook
events,
so
we
can
count
chat
on
on
pull
requests
and
collaborate
in
pull
requests
figure.
Sending
events
in
triggering
builds
so
Jenkins
actually
uses
prowl
uses
text
on
pipelines
to
run
the
builds
Jenkins.
X
also
has
this
concept
of
a
Jenkins,
actually
animal
which
I
mentioned,
and
the
idea
of
this
is
when
prowl
sends
over
our
web
book
events
we
interceptors
in
our
cluster.
C
We
also
have
concepts
or
bill
packs
as
well,
so
the
similar
way
for
for
Jenkins
users
that
might
be
familiar
with
this.
You
can
actually
manage
these
bill
packs,
set
in
a
central
place
and
inherit
from
them
in
your
Jenkins
x/y
amyl,
or
you
can
override
steps
as
well
and
we're
going
to
hopefully
see
this
in
the
live
demo.
C
C
This
is
just
a
diagram
really
done.
This
needs
Assessor.
There's
lots
of
cameras,
that's
good,
but
you
don't
need
to
see
this
too
much.
I
guess
what
we're
trying
to
emphasize
is
Jenkins.
X
is
really
embracing
an
event-driven
architecture
extending
kubernetes
in
the
way
it's
intended
to
be
extended,
watching
the
API
servers
for
events
and
then
interacting
and
running,
build
we're
also
integrating
with
any
open
source
project
that
makes
sense
so
vault
for
secrets.
For
example,
we've
mentioned
Tecton
and
prowl
many
many
others
as
well.
C
Ok,
well,
that
was
quick.
Ok
I'll,
give
you
a
demo,
ok
ready
for
the
demo,
let's
cross
our
fingers.
So
what
I
have?
If
people
can't
see
this
please
shelter
shout
out.
We
have
a
Junkers
accent.
Station
already
been
created,
it's
running
on
Google
container
engine.
It's
a
three
node
cluster,
it
was
creative
with
JX
creates
cluster
gke.
This
is
going
to
install
the
number
of
things
it's
installed.
Tecton,
it's
installed,
prowl
it's
installed
and
everything
we
need
to
be
able
to
build
release
and
deploy
our
applications.
We've
also
out-of-the-box
created
some
environments.
C
So
let's
go
JX
gets
n.
Now
it's
a
bit
of
whip
of
a
screen
map
here,
but
you
can
see.
We've
got
staging
environment
that
it's
production
environments.
This
is
where
we
catch
the
you
can
predefined
these.
You
can
extend
these
as
well.
We
also
have
a
concept
of
preview
environments.
This
is
somewhere
where
we
can
actually
dynamically
spin
up
a
new
environment
and
actually
deploy
a
proposed
change
into
that
preview
environment.
C
So
we
can
start
collaborating
and
testing,
but
before
we
actually
move
that
into
master
we're
going
to
see
this
in
the
demo,
we
also
have
this
concept
of
get
ops
so
for
a
staging
repository,
for
example,
everything
goes
into
a
git
repository.
Any
change
that
goes
into
an
environment
has
to
be
approved.
You
have
traceability,
and
when
that
is
that
changes
merged
an
event
is
triggered
and
then
Tecton.
Actually
then
performs
the
deployment
for
that
for
that
environment.
C
So,
with
that,
let's
go
ahead
and
create
a
quick
starts,
so
CV
workspace
can
remember
to
type
yes,
okay,
that's
JX,
create
quick
start
quick
starts.
Can
everyone
see
that?
Okay,
anyone
not
be
able
to
see
that
okay,
okay,
so
I've
already
got
like
my
local
get
credentials
locally,
because
I'm
going
to
create
a
brand
new
git
repository
and
set
up
all
the
web
perks
set
up
all
the
cin
CD
everything
needed
to
be
able
to
build
and
run
that.
So
that's
what
use
might
github
username
and
we're
going
to
use
a
shared
organization?
B
C
So
we're
going
to
have
a
list
of
quick
starts:
we've
got
a
bunch
of
quick
starts,
which
are
probably
the
most
simplest
quick
starts.
You
could
possibly
imagine
it's
read
just
to
demonstrate
and
every
different
language
do
you
care
about.
We
can
actually
build
and
deploy
them
burn
these
applications,
and
you
can
also
extend
and
have
your
own
quick
starts,
because
these
come
from
a
git
repository.
You
point
it
Jenkins
X
to
a
github
organization
or
get
organizations
and
you'll
be
able
to
get
your
own
quick
starts.
C
B
C
Okay,
so
we've
also
added
a
bot
user,
as
well
as
a
collaborator
on
the
projects
that
we
can
actually
start
making
commenting
and
actually
having
automation
around
on
that
git
repository.
Alright,
what
should
have
happened
here
is
okay,
something
really
really
happened
very
very
fast
there
we
actually,
let's
not
do
that,
and.
B
C
So
let's
have
a
look
in
here.
We've
got
the
very,
very,
very
simple
go.
This
is
really
not
going
to
do
very
much
because
spin
up
a
simple
web
page
with
the
hello
world
message.
This
is
our
example
of
a
go
project,
but
then,
what's
also
interesting
is
we've
actually
done
language
detection
and
addy
the
dockerfile,
because
we
know
it's
go.
We
know
how
to
build
that.
We've
added
a
jenkins
HTML
file,
we've
also
added
helm,
charts
to
be
able
to
package
and
run
that
application
on
on
kubernetes.
C
B
C
Okay,
so
we
see
a
build
here
and
that's
reading
and
that's
probably
running
along
here:
let's
move,
what's
kind
of
college
in
the
green
on
the
end
of
the
screen.
What
you
can
actually
see
is
the
build
steps.
Now
these
are
the
multiple
steps
from
the
Tecton
pipeline.
So
he's
a
different
containers
running
inside
the
pod
and
you
can
see
these
are
logs
and
we
are
actually
oh
there
we
go.
We've
had
we've
built
the
image.
We've
done
a
built,
a
docker,
build
with
calico
push
that
into
GC
are
I.
C
Probably
yes,
because
everything's
going
really
really
quickly
and
we
can
see
this
is
just
adding
in
this
we're
using
a
helm
at
the
moment
here
to
be
able
to
add
in
that
application.
So
any
new
versions
or
new
applications,
any
upgrades
you
would
actually
get
automatically
updated
in
this
repository
so
because
that's
been
merged
we
should
have
seen.
Also,
let's
run
that
again,
we
have
a
promotion
into
our
staging
repository
as
well.
So
we
can
see.
That's
actually
all
that's
running
at
the
moment,
and
all
this
is
going
to
do
is
take
that
packet.
C
C
C
B
C
Carlos
will
probably
kill
me
for
sparing
that
wrong
probably
have
okay,
we
also
made
to
change
there,
but
let's
also
have
a
look
at
our
Jenkins
x
llamo.
Now,
if
you
can
see
this
we're
actually
looking
at
the
inheriting
from
the
build
pack
that
bill
pack
is
on
github
somewhere,
you
can
craft
your
own
build
packs,
but
what's
really
really
cool
now
is
we
have
should
work
now
we
now
have
a
generated
schema
that
we
build
and
release
on
it
on
every
release
of
Jenkins
X.
C
So
we
have
syntax
validation
and
Co
completion
from
in
your
IDE
to
be
able
to
start
extending
that
build
pack,
so
you
can
now
start
extending
overriding
adding
steps
before
and
after
as
well.
So
it's
really
really
powerful
and
you
get
a
lot
faster
feedback
as
developers
to
be
able
to
try
things
out
experiment
with
your
pipelines.
Okay,
if
I
can
remember
exactly
how
to
do
this.
One
pipeline,
config
pipelines,
pull
request.
Yes
on
the
pull
request,
pre
build.
Let's
add
in
a
step
of
okay
container
busybox,
see
how
we
doing
for
time
busy
box.
B
C
C
And
remembering
we're
about
prow,
this
is
going
to
send
a
web
hook
event
into
the
cluster
files
going
to
intercept
this
because
I
can
handle
this,
and
then
it's
going
to
start
commenting
back
on
this
pull
request.
Some
simple
plugins,
like
the
analyzer,
the
size
of
the
change
that
helps
for
reviewers.
It's
also
said
it's
not
approved
yet
so
that's
okay!
This
means
we
can
do
some
real
sensible,
really
takes
really
really
seriously.
C
These
there's
some
good
great
work
on
pull
requests,
and
this
is,
you
know,
absolutely
regards-
can't
emphasize
the
seriousness
of
all
of
this
okay.
So
what
we're
talking
about
is
being
able
to
collaborate.
This
is
what
we're
trying
to
demonstrate.
We
wanna
merge
as
Matt.
We
want
to
shift
as
much
as
we
can
do
into
the
sea
ice
shifting
left
to
shift
our
security
checks
as
automated
our
testing.
So
we
can
be
as
sure
as
possible
when
you
merge
that
change,
then
that
could
be
shipped
through
to
your
to
your
production
environment.
C
Beautiful
all
right,
okay,
so,
what's
that's
actually
doing?
Is
it's
running
a
Tecton
build
that's
going
to
dynamically,
create
as
a
preview
environment
if
I'm,
if
you
remember
working
before,
let's
also
say,
did
that
other
build
happen,
that
we
were
looking
at
before.
J
X
get
applications,
so
that's
our
during
a
time
travel.
This
is
our
message
from
our
goal,
allowing
simple
goal
and
quick
start
that
we
had
and
that's
running
in
our
staging
environment.
That
was
automatically
deployed
right.
Okay.
What
we
should
have
now
is
that
is
now
running.
That's
doing
the
bill.
B
C
Oh
we've
had
a
comment
by
the
bot
user
on
our
pull
request
that
that
preview
environment
has
been
created
and
we've
taken
that
change
and
deployed
that
out
into
our
preview
environment.
It's
going
to
have
a
look
at
this,
and
here
we
see
this
really
means
we
can
start
collaborating
a
lot
more
on
pull
requests
and
shifting
that
left,
making
as
sure
as
possible
that
we've
that
that
change
is
supposed
to
do
what
it's
supposed
to
do.
Okay,
I
think,
that's
pretty
much
regret
from
a
from
a
demo
point
of
view.
C
D
Okay,
so
another
interesting
thing
that
you
might
want
to
take
note
of
is
in
March.
We
were
really
excited
to
donate
these
projects
to
a
new
foundation
called
the
continuous
delivery
foundation.
So
this
is
a
foundation
that
we've
created
as
a
place
where
we
can
all
collaborate
and
really
push
forward,
see
ICD
into
into
the
modern
day.
I
lost
my
clicker.
C
But
we're
absolutely
excited
because,
just
as
as
kubernetes
and
the
projects
open
source
projects
can
flow
us
around
with
the
CNC
F
as
well,
we
can
get
some
live
standardizations
around
CIC
D,
which
we
all
absolutely
need.
We
want
to
help
everybody
to
be
able
to
build
better
software
faster.
This
is
a
this
is
a
great
foundation
itself.
This
enabled
us
to
do
that
and.
D
So,
that's
all
that
we
have
for
you
today
if
you're
interested
in
more,
you
can
check
out
info
about
the
cdf
and
if
you
want
to
dive
in
and
get
started
on
our
projects,
you
can
check
out
the
quick
starts.
You
can
check
out
the
contributing
guides
that
we
have
in
all
of
our
repos
as
well,
and
that's
it
thanks
very
much.