►
Description
What's new with Jenkins X 3 - James Rawlings & James Strachan, CloudBees
Speakers: James Rawlings, James Strachan
This session will cover the architectural improvements and new features of Jenkins X v3. We'll dive into the key areas that have undergone major development. GitOps: a better approach to installation and upgrades leveraging Helmfile, using an in-cluster operator to apply desired state stored in Git. Secrets: out of the box integration with external secret management solutions such as Google + Amazon cloud services Infrastructure: decoupled infrastructure management using Terraform UX: hosted dashboard to link your pull request logs along with a local Octant UI for deeper cluster visualisations. Cloud Native Pipelines: now using vanilla Tekton pipelines with no abstraction layer. Along with Lighthouse to handle both in repo and shared pipeline definitions we now have a clean, extendable way to describe pipelines. Health: health checks and insight via Grafana
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
Thank
you
james,
so
next
slide
yeah.
So,
firstly,
what
is
jenkins
x.
So
let
me
do
a
quick
one
minute
overview.
What
jenkins
x
is
for
those
of
you,
who've
not
seen
it
before
so
jenkins.
X
is
an
open
source
project.
It's
part
of
the
cdf
and
it's
aimed
at
trying
to
automate
cicd
on
kubernetes,
so
once
you're
using
jenkins
x,
it
will
automate
your
ci
and
cd
for
you.
B
B
It
also
adds
something
called
preview
environments.
So
whenever
you
create
a
preview
or
in
a
pull
request,
we'll
create
a
brand
new
environment
in
kubernetes.
I
will
run
your
software
in
that
preview
environment.
So
your
team
can
give
you
fast
feedback
on
your
code
change
before
that
change
merges
into
the
main
branch.
So
it
gives
you
super
fast
feedback.
B
B
So
here's
a
quick
start,
I've
already
imported
into
jenkins
x
and
I'm
going
to
modify
this
awesome
home
page
of
this
microservice
and
I'm
going
to
say
very,
very
awesome,
hello,
very
awesome
stuff
and
I'm
going
to
say
this
fix
and
you
add
small,
that's
more
awesome!
I'm
going
to
create
a
branch
and
a
pull
request
for
this.
I'm
going
to
propose
this
code
change
and
I'm
going
to
create
a
pull.
B
B
B
We
can
see,
there's
a
link
there,
I'm
going
to
open
that
link
in
a
new
window
and
that
link
is
to
the
jenkins
x,
dashboard.
The
jiggers
x
dashboard
is
a
read-only
visualization
of
all
of
the
repositories
and
pipelines
that
are
running
inside
your
cluster.
So
it's
very
easy
to
link
from
your
pull
requests
and
your
releases
in
your
git
provider
to
this
ui.
So
we
can
visualize
what's
happening
so
we've
created
a
pull
request.
B
B
B
B
So
using
opt-ins
you
can
visualize
deployments
and
pods
and
secrets
and
config
maps
and
ingresses
and
all
of
the
different
custom
resources
that
are
inside
your
cluster.
If
you're
using
kubernetes
to
develop,
deploy
and
test
kubernetes
centric
applications,
you
do
need
to
at
some
point
look
at
the
cluster
when
things
go
bad
or
trying
to
diagnose.
If
things
are
running
properly
so
often
is
an
awesome
user
interface
for
looking
inside
your
cluster
obtain
runs
locally
on
your
laptop
and
then
uses
your
the
same
access
control
that
works
with
cube
cuddle
or
the
jx
command
line.
B
So
it
basically
uses
secure
ways
to
access
your
cluster.
It
works
well
with
kubernetes
role-based
authentication
that
lets
you
visualize
everything
that
you're
allowed
to
see
in
the
kubernetes
cluster.
Now
octane
has
a
plug-in
mechanism
so
that
it
lets
you
extend
opt-in
to
provide
different
user
interfaces
and
we
have
a
plug-in
for
junkies
x,
that
visualizes
jenkins
x
resources,
like
pipelines,
pull
requests,
preview,
environments,
applications
and
so
forth.
B
B
What
we
often
want
to
do
when
we've
got
a
team
working
together
via
say,
get
repository,
we
want
to
be
able
to
easily
link,
get
pull
requests
and
releases
on
git
repositories
to
pipelines
and
logs,
and
that's
where
the
dashboard
comes
in.
So
the
dashboard
is
basically
a
read-only
web
user
interface
to
let
you
visualize
pipelines
and
logs
and
steps
for
pull,
requests
and
releases.
B
B
Finally,
there's
the
command
line.
We've
always
had
the
command
line,
and
so
there's
a
nice
simple
command
line
for
those
who
prefer
command
lines
to
web
frontends
and
so
forth.
In
addition,
we
have
a
slack
plugin
now,
so
you
can
get
the
slack
plugin
to
notify
you
on
say,
failed
releases
or
it
can
direct
message
you,
when
your
pull
requests
are
triggered
in
pipelines
from
there
next
slide,
please
james.
B
Here's
a
quick
example
of
on
the
left,
the
octane
user
interface
and
on
the
right.
The
dashboard
use
interface,
so
they're,
nice
and
clean
excellent,
and
one
of
the
big
changes
in
v3
of
jks
is
the
architecture
so
from
30
000
feet.
It
looks
and
feels
very
similar
to
jenkins
xv2,
it
automates
the
icd
and
it
creates
pull
requests
and
preview
environments
and
all
that
kind
of
stuff
under
the
covers.
The
architecture
has
changed
quite
a
lot.
One
of
the
biggest
changes
is
in
v2.
B
We
used
to
have
this
monolithic
command
line
now
in
v3.
Every
single
command
in
the
cli
is
a
completely
separate
plugin.
Anybody
can
write
new
plugins
in
the
command
line
and
everything
is
kind
of
nicely
decoupled,
so
we
have
a
plugin
for
github.
So
looking
for
working
with
secrets,
a
plugin
for
administering
and
clustering,
some
and
so
forth,
so
decoupling,
the
cli
has
been
a
big
big
bonus.
A
Excellent,
just
just
to
add,
I
think,
one
of
the
things
in
here.
I
guess
one
of
the
big
differences
from
v2
that
people
might
be
familiar
with
was
we
used
to
have
a
cli
to
boot,
up
the
installation
and
install
all
the
resources
into
a
cluster,
and
that
was
run
from
the
user's
laptop
connecting
into
a
cluster
and
we've
got
in
here.
This
is
there's
the
git
operator,
which
is
basically
it's
an
operator
running
inside
the
cluster.
A
So
it's
a
real
lightweight
operator
which
is
just
polling
for
changes
in
a
cluster
git
repository
now
embracing
githubs.
Everything
that
goes
into
this
cluster
is
via
change
to
pull
requests
onto
a
repository,
and
so
when
that's
approved
and
merged.
That
change
is
then
generates
new
yaml
and
then
reflected
inside
synchronized
inside
the
cluster,
using
the
git
operator
so
another
one
of
the
big
differences,
probably
from
from
v2
it's
the
same
environment.
We
had
so
many
issues.
People
should.
B
Yeah,
that's
the
great
point.
I
think
another
thing
we
used
to
have
like
essentially
a
custom
installer
and
the
custom
installer
was
completely
separate
to
how
we
did
promotions
of
your
applications,
whereas
now
in
v3
we
just
have
a
single
way
of
deploying
anything
in
any
cluster,
whether
it's
jks
itself,
whether
it's
your
applications,
whether
it's
you
know
various
plugins
like
cert
manager,
external
dns,
nginx
whatever.
So
we
basically
just
have
one
way
of
doing
everything
by
github's,
which
has
made
everything
much
much
simpler,
more
flexible.
A
Yeah,
I
mean
again
just
as
well
another
one.
There
was
like
things
like
cuba,
healthy,
where
we've
added
in
more
services
to
actually
help
with
them
to
know
when
things
are
not
going
so
great
or
whether
you
draw
your
attention
when
something's,
not
quite
right.
So
we
have
custom
checks
to
be
able
to
for
the
installation
or
for
different
features
of
when
jenkins
x
is
running
web
hook,
checks
and
various
other
checks
that
are
running.
B
Yeah,
absolutely,
I
think
lots
of
the
lots
of
the
changes
in
v3
have
been
really
around
how
to
make
it
easy
more
flexible.
So
it's
easy
to
use
in
different
platforms.
We
support
much
more
much
a
lot
more
platforms
now
such
as
you
know,
really
easy
to
use
on
premise.
We
support
openshift.
We
should
for
all
the
big
three
clouds,
but
it's
much
easier
for
you
to
change
your
installation
to
use
different
storage,
backends
secret
providers
and
various
other
kind
of
things
so
yeah,
that's
a
big
change.
Yeah.
A
A
It's
using
using
git
as
a
way
to
for
to
protect
to
introduce
changes
into
your
cluster
by
and
providing
traceability
and
approvals,
and
then
you
can
actually
look
at
histories
and
using
developer
and
operational
ways
of
working
to
control
changes
going
into
a
class
days.
It's
proven
really
really
well,
it's
a
lot
of
people
are
using
this,
and
this
provided
a
much
cleaner
way
to
be
able
to
understand.
What's
going
inside
the
cluster
and
protect
clusters
and
one
of
the
things.
One
of
the
challenges,
though,
is
using
get
options
is
around
secrets.
A
So
what
the
one
of
the
things
we've
looked
at
with
b3
is
actually
using
an
open
source
project
called
external
secrets,
which
is
now
part.
I
think
it's
one
of
the
six
for
kubernetes.
The
idea
is,
is
an
external
secret
controller
runs
inside
a
cluster?
You
can
see
in
the
middle
here,
so
there's
a
controller
there.
All
it
does
is
allow
it
polls,
an
external
secret
provider
such
as
vault
or
google
secrets
manager
and
there's
a
couple
of
other
ones
as
well.
A
Basically,
cloud
providers,
secrets
managers
and
it
polls
for
real
secrets
that
are
stored
there.
So
what
this
happens
is
in
this
whole
when
we're
using
embracing
githubs,
it
means
that
we
can
we
can
generate.
We
can
make
add,
pull
requests
onto
our
cloud
on
sorry
onto
our
git
provider.
For
our
cluster
we
can
add
a
helm
chart.
A
For
example,
inside
there
there
may
be
a
kubernetes
secret
now,
when
those
when
we
have
when
we
detect
changes
from
our
boot
operator
inside
the
cluster,
we
actually
we
see
that
there's
a
cube
in
this
secret
inside
that
helm,
chart
when
we
template
the
yammer
and
we
actually
switch
that
to
be
an
external
secret.
This
external
secret
is
a
custom
resource
from
the
external
sequence
project.
A
It's
just
a
placeholder
that
points
to
different
places
within
your
sequence,
provider,
of
where
how
the
controller
for
the
sequence
controller
can
go
retrieve
and
fetch
the
real
sequence
values,
there's
quite
a
lot
going
on
here,
but
we're
going
to
have
a
little
demo
just
to
kind
of
demonstrate
to
explain
this
here
now.
So
with
that
in
mind,
let's
try
and
switch
this.
A
A
There
we
go
so
let's
do
cubes
ctl
nodes,
so
we've
got
a
nice
cluster
here
and
we've
installed
jenkins
x
already,
so
we
actually
have
already
a
an
application
running
in
our
staging
environment,
so
we
can
go
into
the
name
space
for
season,
environment,
cube
ctl,
and
here
we
can
see.
We've
got
an
application,
that's
running
here
now
earlier
on
today.
What
we
did
was
added
in
a
to
our
application
with
it's,
the
ci
cd
is
being
provided
by
jenkins
x.
So
any
change
we
push
into
this
repository
gets.
A
The
pipelines
are
run
within
this
cluster.
The
the
chart
is
then
added
onto
the
cluster
gate
repository,
which
contains
a
secret.
Let's
have
a
look
at
this.
You
can
see
we
added
in
a
kubernetes
secret,
and
that
says
my
secret
with
two
values
of
username
and
password
through
mumbai
and
when
we
go
back
to
our
view
outside
here,
that's
a
helm
chart
that's
generated
the
helm
chart
that
contains
community
secret
and
when
this
was
released,
the
release
pipeline.
Let's
have
a
look
at
this.
A
A
So
let's
go
and
have
a
look
at
this
here
we
can
see.
We
had
a
the
promote
step,
was
a
helm,
chart
version,
update
of
version
0.8,
and
that
was
added
on
to
our
staging
environment.
Now
what's
interesting
is
that
is
the
change
here.
That's
been
pushed
onto
our
cluster
git
repository
changes
were
detected
and
now
the
the
git
operator
has
generated
has
templated
all
the
ammo
from
that
helm,
template
and
has
swapped
the
kubernetes
secret
with
the
external
secret.
So
let's
go
and
have
a
look
at
this.
A
You
can
see.
We've
got
a
regenerator
pull
request
and
in
here
you
can
see
rather
than
the
kubernetes
secret.
We
now
have
our
x
thing
or
secret,
and
these
are
the
places
the
coordinates
have
go
where
to
go
and
find
the
real
value
for
that
secret
in
google
sequence
manager,
which
has
been
configured
so
when
that
gets
merged,
then
going
back
to
our
diagram
that
gets
merged
and
the
applied.
So
we've
got
an
external
sequence
resource
actually
inside
the
cluster.
A
A
A
So
what
this
is
doing
is
that's
going
to
talk
to
our
sequence
provider,
which
in
this
case
is
google
sequence
manager
and
it's
going
to
create
a
new
version
here
and
that's
going
to
the
sequence.
Control
is
going
to
detect
that
change.
It's
going
to
go
and
fetch
that
sequence
and
populate
see
the
kubernetes
secret.
A
A
A
A
Now
that
should,
at
some
point
now,
there's
a
polling
that
on
that-
and
here
we
see-
we
can
see.
Our
secret
has
now
been
reflected
inside
the
cluster,
so
we're
using
githubs
to
control
every
change
that
goes
into
the
cluster,
but
without
actually
checking
in
real
secret
values
into
the
git
repository.
Instead
using
real
secrets,
managers
which
are
great
for
recycling
and
revoking
secrets,
managing
secrets
well
and
rather
than
the
git
repository.
B
A
B
Sure
I'll
go
quickly
because
we've
really
got
a
time,
but
one
of
the
other
big
changes
in
v3
is
we
used
to
have
a
domain-specific
language
that
was
kind
of
like
an
abstraction
above
jenkins
pipelines
and
tecton
pipelines
with
v3.
Did
we
decided
to
go
all
in
on
just
using
vanilla,
texture
and
pipeline
yellow?
B
B
So
we've
put
in
place
a
very
simple
model
where
we
can
share
entire
pipeline
tasks
and
steps
across
all
of
your
repositories.
So
you
don't
need
to
list
the
specific
image,
tags
and
versions
you're
using
of
all
of
the
different
steps,
and
you
have
to
specify
what
the
steps
do.
You
can
just
reference
them
by
name
in
a
catalog,
but
we
also
have
a
simple
way
of
overriding
steps
locally.
So
if
you
want
to
specifically
modify
say
the
command
line,
arguments
of
a
step,
you
can
do
that
locally
in
your
git
repository.
B
Meanwhile,
you
can
share
the
details
of
that
step
in
your
catalog,
so
this
very
simple
change
means
you
can
use
vanilla,
tecton
tooling,
to
edit
your
pipelines,
but
by
default
we
can
share
those
text
on
yammers
across
all
of
your
repositories,
which
proved
super
super
useful
and
one
other
thing.
So
we
have
a
bunch
of
different
jx
pipeline
commands
to
help
you
with
this
there's
jx
pipeline,
effective
to
visualize
the
effective
pipeline
that
shows
the
actual
pipeline
that
would
run
without
having
to
kind
of
copy
and
paste
all
the
shared
fragments
of
tecton.
B
There's
jx
pipeline
lint,
which
will
lint
you'll,
get
your
positive
to
make
sure
you
haven't
messed
up
any
kind
of
tecton
gamma
and
there's
also
a
jx
pipeline
override
that
lets.
You
override
a
specific
step
so
that
you
can
change
a
step
from
a
catalog
super
easily.
So
all
of
these
changes
together
means
it's
easier
to
reuse,
tecton,
catalog
tests
or
any
tech
tone
yaml
you
ever
see
on
the
internet,
but
also
we
it's
much
easier
to
share
pipelines
across
repositories,
which
is
super
useful.
A
Okay,
yeah
so
just
very
quickly
one
of
the
big
things
we've
felt
with
jenkins
one
and
two
was:
we
were
really
embracing:
continuous
delivery,
doing
lots
and
lots
of
releases
per
day,
which
was
great,
but
it
was
really
hard
for
users
to
consume
this
amount
of
change.
So
one
of
the
things
we
started
to
look
at
with
v2
was
the
concept
of
version
stream.
A
A
We
have
multiple
git
repositories
for
these
quality
gates
which
go
at
different
cadences,
so
you
can
go
on
the
latest
version
stream
and
you
can
track
the
latest
bleeding
edge
changes
or
you
can
go
on
slower
cadence,
which
gets
released,
maybe
one
or
two
months
or
you
can
have
your
own
custom
one
as
well.
One
of
the
big
advantages
that
we've
got
with
v3
was
a
project
called
kept
kpt.
A
This
is
a
way
of
basically
synchronizing
using
git
yaml
files.
So
it's
perfect
for
synchronizing
changes
between
of
any
change
that
we
do
because
everything's
clarity,
because
everything
is
the
ammo
base
that
we're
using
in
jenkins
x.
We
can
now
now
sync
these
changes
into
your
own
cluster
git
repository.
So
when
we
perform
a
release,
you
can
easily
consume
that
change
and
we
have
multiple
bdd
testing
on
various
different
things
and
which
you'll
see
on
the
next
slide,
all
the
different
things
that
we've
been
integrating
and
working
with
and
testing
it.
A
But
it's
a
real.
I
think
we'd
really
feel
a
lot
happy
and
the
feedback
we've
had
about
this
change
of
using
kept
consume.
These
changes.
It's,
I
think
one
quote
you
see
later
on
that
somebody
hadn't
upgraded
for
three
months
and
did
one
jx
get
ups
upgrade
and
they
got
all
pulled
in
all
the
changes
and
could
do
a
diff
of
all
the
upgrades
and
all
the
changes
into
their
cluster.
It.
B
Makes
it
much
easier
to
understand
what's
happening
like
what
is
in
that
upgrade
like
what
exactly
changed,
and
why
did
it
change
so
you
can
it
helps
you
diagnose
things.
I
think
one
of
the
things
one
of
my
favorite
features
of
v3,
I
think,
is
every
kubernetes
resource
is
versioned
in
git.
So
if
anything
goes
wrong
with
a
particular
like
deployment
or
powder,
whatever
you
can
just
look
at.
When
did
this
deployment
change
in
history,
which
is
super
super
awesome?
B
B
If
you
want
to
get
started
on
the
next
slide,
if
you
go
to
the
jigsex
website,
there's
guides
for
all
the
different
card
providers
and
all
the
different
kind
of
setups
you
wish
so
follow.
Whichever
guide
suits
the
cluster
that
you're
using
go
there,
we
should
give
a
big
hat
tip
to
the
observability
work
that
particularly
vincent
has
done,
which
is
truly
awesome.
We
basically
have
really
awesome
integration
with
a
various
grafana
projects.
B
We
found
them
in
loki
and
various
other
pieces
that
make
it
super
easy
to
visualize
metrics
of
all
of
your
pipelines
and
to
visualize
traces
using
open,
telemetry
and
whatnot.
So
you
can
see
exactly
what's
happening
with
all
of
your
pipelines.
How
long
we
all
took
and
get
all
of
those
awesome
metrics
and
your
devops
metrics
all
done
in
a
open
source.
Graphing
dashboard,
which
is
truly
truly
awesome,
definitely
check
that
one
out.
A
Worth
mentioning
very
quickly
as
well,
if
it's
not
already
been
then
vincent's
doing
the
talk
on
this
as
well
so
go
and
take
a
look
at
that
talk
or
catch
up
on
video
afterwards.
Definitely
just
some
community
feedback
and
again
we
rely
on
the
community
the
community's
involvement
to
help
build
and
develop
and
evolve
this
with
jinx
x3.
So
we're
very,
very
proud
and
just
a
big
thank
you
to
everybody.
That's
helped
get
this
this
far,
it's
been
a
real
community
team
effort
and
it's
been
lovely
to
be
a
part
of.
A
And
then,
just
to
finish
off,
there
is
to
find
out
more
go
to
the
websites
at
jenkinsx.io
and
there's
some
walkthroughs
video
walkthroughs.
We
love
hearing
people's
stories
and
contributing
your
own
blogs
and
videos
and
feedback
as
well,
come
and
say
hello
on
slack
channel
or
twitter.
We
love
to
hear
everything
anything
about
you
have
and
we
hope
that
you've
enjoyed
this
talk
and
we're
going
to
have
some
questions.
There.
B
A
B
So
one
of
the
questions
was
open
policy
agent,
integration,
which
we've
not
really
done
that
with
the
policy
agent.
Yet
we
do
have
a
plug-in.
That's
around
various
validation
and
I'll,
dig
out
a
link
in
a
second
there's,
a
whole
raft
of
different
projects
for
doing
validation
of
kubernetes
resources.
It's
slightly
different,
but
some
people
use
open
policy
agent
to
assert
that
certain
things
can
and
can't
be
done
on
the
cluster,
but
also
some
people
use
open
policy
agent
as
like
a
domain
specific
language
to
validate
resources
before
they
get
applied.
B
So
it's
a
it's
a
form
of
testing,
so
we
do
have
a
plug-in
which
I'll
find
in
a
second
that
helps.
You
use
the
various
different
tools
as
part
of
your
pipeline.
There's
a
whole
raft
of
these
tools,
so
we've
basically
integrated
with
most
of
them.
I'll
show
you
in
a
second
cube
test.
That's
it
here's
the
plugin
I'll
post
it
in
the
chat
and
cube
test.
Lets
you
basically
enable
and
disable
various
different
tools.
B
Conf
test
is
a
plug-in
tool
that
lets
you
use
open
policy
agent
assertions
to
validate
the
yaml
in
your
charts.
It's
valid,
there's
qb
valve
that
does
schema
validation,
it's
fairly
simplistic,
but
it
very
well
is
your
schema
valid
and
you
haven't
made
a
mistake:
cube
score
rates.
The
r
has
a
scoring
mechanism
to
do
specific
validation
of
your
yaml
and
polaris
is
kind
of
similar
as
well.
B
A
Yeah-
and
it's
also
really
one
of
the
benefits-
I
guess-
of
using
external
secret
providers,
because
a
lot
of
them
have
these
kind
of
ways
to
rotate
secrets
as
well
and
now
what's
actually
happening
is
in
that
in
that
talk
there
we
have
this,
there's
an
there's,
a
controller
running
inside
the
cluster
and
that's
just
polling
checking
for
updated
secrets
in
this
real
secret
store,
like
google
sequence,
manager
or
vault.
So
when
they
get
rotated
in
the
secret
store,
they
then
get
reflected
inside
jenkins
x
as
well.
A
There
was
actually
another
good
question
above
earlier
about
if
there's
an
environment
variable,
that's
loaded
from
the
secret,
how
do
you
kind
of
bounce,
the
pod
so
that
the
environment
variable
gets
updated
and
there's
a
link
in
the
chat
to
we
use
something
called
push
a
wave
that
helps
up
that
watches
for
secret
changes
and
then
can
actually
restart
pods,
so
they're
rolling
about
a
basic
deployment.
So
you
get
a
rolling
upgrade
of
the
pod.
B
There
was
a
great
question
for
what
a
couple
of
questions
have
just
come
in
brian's
question
was:
can
we
convert
v2
pipelines
to
tecton?
Yes,
there's
a
link
there.
We
have
a
converter
that
does
it
for
you,
which
is
great
the
really
nice
thing
by
the
way
in
v3,
we've
gone
all
in
on
the
tecton
syntax.
B
Now,
in
many
ways,
if
you
look
at
the
yamls
they're
kind
of
similar,
but
the
great
thing
is
the
text
on
syntax
is,
is
now
understood
by
vs
code
and
intellij,
with
plugins
from
red
hat,
so
you
get
really
nice
type,
completion
and
validation
and
those
and
so
forth
so
yeah.
We
we
love
the
the
use
of
tekton
syntax
and
it's
more
interoperable.
You
can
use
anything
for
the
technical
catalog.
Anything
you
see
on
the
internet,
that's
ticked
on
you
can
just
copy
and
paste
bits
and
use
it
in
your
pipelines.
B
They're
very,
very
different,
if
ever
you've
looked
at,
say
jenkins
files
and
say
git
of
actions
and
techton
they're
all
kind
of
different
on
the
plus
side.
If
you
look
at
almost
anything
else
but
jenkins
files,
so
if
you
look
at
circleci
or
travis
or
drone
or
github
actions,
all
of
those
stuff
look
basically
about
the
same,
the
yaml
they
run
steps
in
containers,
it's
fairly
easy
to
move
from
one
of
those
to
tecton,
or
vice
versa.
B
They're
pretty
it's
pretty
simple
mechanical
stuff
jenkins
files
are
a
whole
different
kind
of
fish,
because
it's
it's
a
slightly
weird
version
of
groovy.
That's
used
in
jenkins,
that's
complicated
so
that
it
converting
it
automatically
is
really
quite
hard.
A
few
people
have
tried
it
and
it's
never
really
worked.
B
What
I
would
say
is
if
you've
got
a
jenkins
file,
that's
working
just
keep
it
just
keep
the
checkers
file,
don't
touch
it
just
use
it,
as
is
in
jenkins,
and
then
use
jenkins,
x
and
tekton
for
anything
new,
any
new
pipelines,
any
new
projects-
and
you
know
you
don't-
have
to
boil
the
ocean
and
convert
everything
across
from
the
uci
engine.
Just
because
it's
there,
so
I
I'd
go
for
the
simplest
route,
just
use
jenkins
when
you've
got
a
jenkins
file
that
you
need
use,
jenkins,
x
and
text
of
everything
else.
A
I
was
also
going
to
say
I
added
to
that
as
well.
What
some
people
have
done
is
run
them
in
parallel,
so
you
can
have
multiple
web
hooks,
one,
that's
sending
for
a
repo
on
sending
to
traditional
jenkins
for
you
jenkins
file,
but
also
sending.
If
you
want
to
start
adding
more
parallel
pipelines
with
techton,
then
you
can
start
out
building
those
up
like
linting
and
various
other
pipelines.
So
you
can.
You
can
certainly
run
the
two
in
parallel
and
certainly
move
things
over
as
and
when
your
project
you
have
time.
B
Moving
from
jenkins
files
to
junkies
x
is
a
slightly
more
complicated
thing
and,
as
james
was
just
saying,
it's
easy
just
to
start
off
just
important.
You
use
use
jenkins
x
for
new
projects
and
automate
the
ci
cd
for
new
things,
keep
the
old
stuff
where
it
is,
and
you
know
with
whatever
jinx
files
you
have
and
then
you
can
try.
You
know
run
it
in
both
and
see.
B
B
Yeah,
we're
probably
totally
over
time.
Are
we
but
yeah
great
questions?
I
keep
them
coming,
I'm
going
to
be
here
for
a
little
bit
longer
and
oh,
we
should
mention
if
ever
you're
playing
around
today
and
you
want
to
get
any
more
help,
I'm
just
going
to
post
a
link
in
the
chat,
there's
a
bunch
of
stuff
on
the
community
page.
B
We
do
every
two
weeks
we're
doing
office
hours
like
a
meeting
where
we
just
turn
up
and
do
demos
and
chats
about
anything,
that's
on
our
minds
and
there's
a
slack
channel
if
ever
you've
got
any
issues
or
wouldn't
ask
questions
or
whatever
so
pop
by
there
after
cdcon.
If
you
want
to
chat
about
anything,
just
pop
by
v3
is
released,
it's
ga.
It's
been
released
for
a
few
few
months
now,
yeah
we've
been
using
production
for
six
months
and
it's
really
awesome
so
definitely
go
with
v3.
B
B
You
know
what,
when
did
the
environment
variable
get
added?
When
did
the
image
change?
When
did
it
work
and
when
didn't
it
work,
so
you
can
easily
use
the
things
we
normally
do
with
code
with
kubernetes,
which
is
a
really
lovely
thing,
and
lots
of
people
are
talking
about
githubs
and
kubernetes,
which
is
great,
but
a
lot
of
people
miss
this
detail
that
checking
in
like
helm,
files
and
yaml
and
all
those
things
is
great,
but
there's
an
end
user.
A
That's
a
that's
a
good
question
just
coming
about
using
sops,
there's,
also
another
approach
to
checking
in
and
encrypted
secrets
into
a
git
repo,
just
a
quick
plug
for
for
cara
de
la
mar.
She
did
a
get
ups
and
secrets
talk
earlier
on
in
the
week
and
also
went
into
a
lot
more
detail
that
we
might
have
time
for
now,
but
yeah.
We
actually
did
used
to
use
this
approach
and
we
found
a
little
bit
a
bit
of
an
overhead.
A
To
be
honest,
because
every
time
a
new
member
of
the
team
came
in,
we
had
to
be
re-encrypt
the
the
secrets
using
gpg
and
it
was.
It
was
a
bit
of
an
overhead
and
also
every
time
we
wanted
to
change
the
secret.
Then
you
have
to
go
into
each
individual
git
repository
having
a
secret
manager
that
is
purely
designed
for
managing
secrets.
It
just
feels
better.
It
feels
right
and
it's
in
the
central
place
and
they
have
rotation
approaches
themselves
and
other
secret
features.
A
B
When
sops
does
work,
but
we've
just
found
external
secrets
is
just
an
easy
ux.
We
had
all
kinds
of
things
that
you
know,
developers
on
the
team
couldn't
even
run
builds
locally
because
they
hadn't
got
their
gpg
keys
in
the
signing
ring
and
all
this
kind
of
stuff.
So
it
it's
just
easier
to
work
with
secret
managers
really.
A
And
and
also
you're
you're
doing
you're
using
you
have
files
that
are
locally
that
are
unencrypted
and
it
just
personally
this
personal
taste,
it's
it
feels
risky.
Things
can
get
leaked
accidentally
and
you
make
mistakes.
People
are
human,
having
them
in
the
secret,
store
and
away
from
your
fingertips.
It's
is
a
lot
better.
It's.
B
Also
much
more
secure
because
then
you
know
you
might
not
give
your
developers
access
to
see
any
of
the
secrets
and
you
can
with
secret
managers,
you
can
have
role-based
access
control
on
every
single
secret,
so
rather
than
decrypting,
every
single
secret
in
the
entire
git
repository
for
absolutely
everything
you
can
have
different
roles
and
different
people
can
see
different
secrets
or
write,
different
secrets
or
read
different
secrets.
So
it
is
much
much
more
secure,
but
hey.
B
You
know
if
you're
using
stops
and
it's
working
for
you
crack
on
that's
great,
but
secret
managers
are
a
bit
nicer
and
a
bit
easier,
particularly
with
the
auto
rotation
as
well
is
another
thing:
that's
particularly
handy
yeah.
It
also
makes
it
easier.
If
you
go,
you
try
to
use
the
same
app
in
many
environments,
it's
easier
to
plug
in
secret
managers
separately
than
having
to
keep
changing
gates
to
swap
all
these
secrets
around.
B
Yeah
yeah
yeah,
that's
that's
a
fair
point
over
you.
You
can
you
set
up
kms
to
help
with
the
decryption,
so
there
are
ways
I
mean
it's.
One
of
those
things
subs
by
itself
is
hard
to
use,
but
you
can
optimize
the
process
a
lot
to
make
subs
easier
and
easier
and
easier,
but
I've
never
seen
it
get
as
close
to
as
easy
as
it
is
to
use
a
real
secret
manager
like
they're
they're.
Just
the
easiest
thing
to
use.
A
Whichever
you
like
yeah,
I
mean
I
mean
that's
the
beauty
of
this.
I
mean
what
what
was
the
same
with
buchenko's
ex.
Is
we
like
get
get
for
things?
So
if
you
want,
you
prefer
using
stops.
If
your
workflows
for
your
teams
use
sops,
absolutely
we're
not.
You
know
you
can
carry
on
using
that.
Absolutely
if
you
will
have
a
secret
management
store,
then
use
that
as
well.
So
it's
that's
the
beauty
of
using
the
github's
approach
that
we've
gone
with.
B
B
We
do
have
some
docs
on
how
to
enable
like
oauth
or
whatever,
on
the
uis,
it's
fairly
easy
to
customize
and
do
whatever
you
want
to
do
so
you
should
be
able
to
use
any
kind
of
authentication,
whether
it's
a
proxy
or
a
service
or
whatever,
but
we
do
have
docs
on
how
to
set
up
oauth
with
the
uis,
basically
with
a
dashboard
but
yeah
that
it
should
be
easy
to
configure
it
to
do
whatever
you
like.
Really
yeah
ui
is
one
of
the
tricky
things
with
uis.
B
A
Posted
the
link,
the
one
drawback
of
the
about
the
oauth
there
is
it
spins
up
a
a
a
proxy
which
is
fine,
but
it's
only
for
one
ingress.
If
you
want
something
more
advanced,
then
using
something
like
decks
is
a
good
alternative
as
well.
So
you
can
have
multiple
endpoints
securing
everything
all
of
your
applications
using
that
approach.
But
it's
it's
a
you
have
to
it's
a
bit
to
get
your
head
around.
To
be
honest,
so
it's
you
know
maybe
set
aside
some
time
to
figure
that
out.
B
How
does
jks
work
with
commercial
cloud
these
jenkins?
That's
a
pretty
good
question.
It
mostly
doesn't,
in
other
words,
staff,
see
them
in
jackie's
ex
or
stuffs
in
crabbies
jenkins,
and
you
you
pick
which
one
you
want
to
use
for
any
particular
job.
Now.
What's
really
interesting,
a
lot
of
people
don't
realize
is
you
can
have
pipelines
running
in
git
of
actions
in
jenkins
x,
with
tecton
and
in
cloud-based
jenkins,
all
on
the
same
repository,
so
it's
it's
not
really
an
either
or
so
for
any
repository.
B
You
could
do
linting
in
jenkins,
x
or
something
or
you
could
do
preview
environments
with
jks
but
use
cloud-based
jenkins
for
releases,
because
you've
always
done
it
like
that
or
whatever.
So
you
can
mix
and
match
different
ci
tools
and
tooling,
I'm
hoping
that
longer
term
jks
will
have
more
cooperation
with
cloudbees's
ci
project
product.