►
From YouTube: auto-deploy with CNG/helm
Description
Delivery and Distribution get together to discuss what's the best approach towards enabling auto-deploy for our Kubernetes based infrastructure for GitLab.com deployments.
A
So
welcome
everyone
again.
The
point
of
this
meeting
is
to
help
understand
how
the
delivery
team
can
enable
all
of
employees
for
our
communities
deployed.
Infrastructure
currently
allowed
to
come
operates
both
omnibus
installations,
which
is
our
primary
method
of
installing
and
operating
gitlab.
Today,
we
need,
because
we
want
to
transition
to
a
crew,
Nettie's
method
of
install.
We
need
to
be
able
to
operate
in
a
way
where
we
can
take
our
CNG
or
help
charts
and
deploy
that
in
a
similar
fashion.
A
A
So
we
send
a
lot
of
out
of
the
ploy
via
our
release
tools
into
omnibus
and
he
performs
a
built-in
tag
and
conveniently
he
triggers
a
deploy,
he
triggers
deployer
to
deploy
the
omnibus
specific
infrastructure
right
now,
any
work
that
we
do
for
the
components
we've
currently
migrated
into.
Kubernetes
is
done
manually,
so
they
get
lab
container
registry
as
well
as
our
mailroom
service.
The
versions
of
those
items
are
updated
mainly
for
the
current
time
being,
and
on
top
of
that,
we
deploy
the
stable
variety
of
those
with
our
desire
to
push
sidekick
into
kubernetes.
A
A
That's
too
little
work
out
and
the
other
focus
is
on
helm,
but
there's
a
lot
of
stuff
that
have
not
fully
tested
with
helm
and
there's
some
understandings
of
helm
that
don't
fully
grasp
yet,
which
is
why
I
haven't
really
delved
too
much
into
it,
but
with
either
these
proposals
they're.
Basically
the
same.
It's
utilizing
release
tools
as
much
as
possible
to
get
the
necessary
information
out
of
the
get
lab
repository,
creating
auto
deploy
branches
in
the
necessary
repos
and
updating
the
necessary
files
to
build
it.
Crichton's.
A
A
The
problem
with
that
approach,
though,
is
that
we
leave
a
huge
gap
between
the
ability
to
keep
helm
up
to
date
with
changes
that
happen
outside
of
the
cng,
repo
and
helm.
So
currently,
my
thought
that
this
would
have
to
be
done
manually,
which
has
bad
consequences,
so
the
preference
would
be
to
try
to
figure
out
how
we
can
do
this
with
helm.
A
B
Effectively
part
of
the
tag
release
process
is
you
provided
the
versions
we
then
go
and
grab
those
versions
and
update
all
they
like
versions
down
through
them,
so
you're,
basically
just
updating
the
app
version
in
the
chart,
but
why
am
L
throughout
various
places?
That
then
points
to
the
version
of
the
image
that
you
want.
D
A
So
if
we
wanted
to
enable
all
to
deploy
for
helm,
what
would
be
the
appropriate
way
for
us
to
send
the
appropriate
information
to
helm
charts
so
that
it
nodes
to
pool
the
correct
versions
of
the
components
that
may
or
may
not
be
built
yeah,
because
I
assume,
based
on
that
information?
Those
versions
already
exist
on
our
registries.
Correct
yeah,.
D
So
how
it
works
is
we
we
have
the
release
tools,
the
CNG
builds
during
the
regular
tagging
process
and
because
the
helm
chart
is
kind
of
a
later
stage,
we
have
the
helm
process
happen
only
during
publish.
So
that's
when
the
helm
chart
has
its
stuff
done
so
will
CNG
at
that
point
has
been
completed,
it
does
have
the
the
home
type
does
have
a
wait,
myth
mechanism,
the
first
job-
is
to
it
just
stops
and
waits
for
those
images
to
be
available,
and
it
has
like
a
two-hour
timeout
or
something
like
that.
A
So
it
sounds
like
in
order
for
us
to
do
auto,
deploy
with
him
we
would
need
to
send.
We
would
need
a
mango
release
tools
to
send
the
necessary
component
versions
to
CNG.
First,
that
way,
CNG
performs
the
build,
and
then
we
would
need
to
do
something
with
helm
to
say
this
is
auto,
deploy
here's
the
version,
the
components
you're
going
to
be
using
and
we
could
probably
rely
on
the
existing
wait
command
of
that
first
job
for
it
to
build
a
chart.
D
I
think
so,
where
the
where
it
isn't
like
set
to
the
same,
where,
where
there
isn't
already
code
in
the
hump
chart
versus
CNG
CNG,
we
had
that
variables
file
right
that
we
were
able
to
update
in
the
helm
chart.
We
really
only
pass
it
to
get
lab
version
and
the
ref,
and
then
it
has
a
script
that
then
goes
out
and
finds
the
appropriate
versions
from
the
get
lab
repo,
which
probably
won't
work
for
auto
deploy.
I'm
guessing
I
was.
A
D
Depends
I'm
not
familiar
with
what
state
those
are
in
for
auto
deploy.
I
know.
Italy
was
recently
changed
so
that
those
end
up
being
Shaw's
right
in
the
in
the
auto,
deploy
that
I'm,
not
sure
I
guess
you
would
probably
know
better
than
I
do
what
the
state
of
the
get
lab
tags
are
for
auto
deploy
for
those
roofs.
B
D
Know
that
that
currently
works,
because
none
anticipated
giddily
actually
went
out
in
the
main
release
with
a
sha
instead
of
a
giddily
tag
version,
so
it
actually.
Yes,
our
release
chart
currently
references
a
CNG
tag
that
is
a
shot
and
get
Ali.
So
we
we
do
have
that
piece
working
at
the
moment
yeah,
but
yeah.
We
currently,
we
currently
rely
on
the
versions
that
are
are
in
the
get
library
Bo
at
the
ref
past.
C
B
C
B
And
they
actually
operate
off
of
a
different
image
repository,
so
they
run
off
from
CG
mirror
and
that
actually
is
where
they
do
all
of
their
build
branching.
So
they
actually
pass
in
the
tag
to
that
through
a
trigger
that
trigger
then
comes
back
out
and
then,
when
they
deploy
they're
setting
the
image
tag
to
match
what
their
branch
name
wasn't.
It
pulls
that
in.
D
Yeah
the
work,
the
work
that
was
done
to
support
that
does
does
feed
into
this,
but
it's
we've
already
kind
of
made
use
of
it
in
the
release
tools
now
as
well,
so
yeah
that
that
is
helping
us
for
the
CMG
side.
Here,
yeah
kind
of
looks
like
John
you'd
you'd
probably
be
able
to
keep
going
with
the
CMG
part
of
it
as
the
first
step,
with
helm
being
like
a
manual
step
and
then
getting
the
helm.
One
done
as
a
as
a
second
go.
A
A
D
D
That
is
always
mirroring
any
changes
we
make
and
then
also
we
have
harden
containers
as
well,
so
that
there's
probably
just
it's
it's
there's,
probably
not
blockers
per
se,
there's
probably
just
good
challenges
to
work
with
a
lot,
a
lot
of
changes
to
find
or
to
discover
that
need
to
happen
in
terms
of
limiting
the
auto
deploy
jobs.
I
know
we
did.
We
already
did
a
bit
of
that
lab
sweet
great
for
CNG.
D
We
got
some
of
the
auto
deploy,
prep
work
done,
but
there'll
be
some
need
to
be
some
similar
stuff
done
for
the
helm
chart
for
the
tagging.
For
example,
wolf
either
wanted
to
not
publish
those
tags
or
want
to,
as
you
mentioned,
have
a
separate
repo
for
publishing
those
I
think.
That's
probably
the
most
important
part
is
just
to
make
sure
they
don't
end
up
in
the
regular
helm,
repo,
okay,.
A
So,
for
the
first
step,
we
need
to
make
sure
we
have
images
built
which
I'm
currently
working
on,
which
is
just
mangling
release
tools
to
send
the
appropriate
versions
to
CNG
CNG
will
build
things.
Nothing
special
comes
out
that,
like
we,
don't
necessarily
need
stable
branches
inside
of
our
CNG
repo
correct,
it's
just
a
matter
of
making
sure
he
builds
what
he
needs
yeah
you
need,
you
need
to
tag,
we
needed,
we
need
a
tag,
but
we
don't
need
stable
branches
per
se
or
well
have
stable
branches.
A
D
B
B
When
you
tag
something
and
you're
like
oh
we're,
gonna
tag,
12,
3,
5
and
now
you're
actually
running
on
the
dockerfile
from
like
12
5
and
all
of
a
sudden,
the
helm
chart
that's
doing
12
3
1
is
like
I,
don't
know
what
now
you
want
what
so
stable?
It's
probably
a
good
idea.
We've
gotten
most
of
those
bumps
out
of
the
way,
but
it's
not
do
that
again.
A
Okay,
so
the
next
step
after
we
have
things
building
properly
in
CNG,
is
that
we
would
need
to
send
Hjelm
some
new
information
which
includes
creating
the
auto
deploy
branches
and
tags
for
it.
What
is
the
correlation
between?
Is
there
a
correlation
between
Hjelm
outside
of
the
context
of
reading
component
versions,
out
of
the
gate
lab
repo
to
ask
for
images
outside
of
inside
of
CNG?
D
A
I
guess
my
concern
of
why
I'm
asking
this
question
and
I'm,
probably
asking
it
very
horribly,
but
I
just
want
to
make
sure
that
if
we
build
version,
12
three
of
sidekick
and
we
have
a
stable
branch
of
twelve
five,
which
has
all
the
good
stuff.
But
we
need
something
in
twelve
five
for
that
twelve
three
patch,
like
I,
would
just
want
to
make
sure
that
we
don't
have
something
awkward,
that's
not
included
in
CNG
that
we
need
inside
of
the
helmet
art
when
it
builds
that
composure
builds
the
chart.
Oh.
D
I
see
what
you
mean.
Yes,
there
is
a
correlation
in
that
there
just
ends
up
being
one
as
a
result
of
us
working
somewhat
in
lockstep
at
the
same
time,
on
the
two
right-
and
there
is
a
document
like
our
release-
version
documents
that
kind
of
map
what
version
of
get
lab
maps
to
a
chart
version
and
you
have
to
kind
of
align
those
minor
versions.
So
the
patches
don't
matter,
but
you
have
to
learn
the
minor
versions.
D
So
at
the
moment,
for
example,
that
helm
chart
of
$12
the
helm
chart,
2.6
was
designed
to
work
with
12.6
of
gitlab.
Now
it
probably
will
work
with
you
know
a
version
before
version
afterwards,
but
that's
not
always
the
case.
Sometimes
we
don't
sometimes
that
yeah,
we
don't.
We
don't
test
for
that,
and
often
we
like
explicitly
not
explicitly,
but
sometimes
if
a
change
happens
in
kit
lab,
we
only
accommodate
like
a
change
in
12
seven
that
breaks
the
home
track.
D
A
A
E
Yes,
where
is
my
zoom
window?
No
I
don't
have
any
questions
thanks
for
putting
this
together,
scarback
I
just
kind
of
wanted
to
see
after
this
and
I
joined
a
little
bit
late.
Do
you
think
we're
going
down
the
path
where
we're
going
to
continue
to
set
the
app
versions
in
the
charts
project
and
use
them
as
sort
of
the
default
versions
for
all
of
the
sub
charts
and
not
override
versions
indicates
we're
close
project
that.
A
E
See,
and
does
my
my
comment
in
the
dock
of
the
suggestion
that
we
should
just
treat
charts
the
same
way
we
treat
omnibus
by
having
an
auto
deploy
branch
and
stable
branches
and
just
update
the
versions.
The
same
way
that
we
update
the
versions
in
the
omnibus
get
that
project
by
you
know
updating
the
version
files.
We
would
just
update
the
app
version
files
from
release
tools
and
kind
of
treat
the
charts.
You
know
project
the
same
way
that
we
treat
omnibus
does
that
make
sense.
I.
A
B
Still
aligns
the
actual
content
of
what
the
version
should
be
is
still
currently
alight
right
now,
when
you
go
into
the
chart,
dot,
yml
and
you
set
at
version,
if
you
give
it
a
specified
one,
and
it
will
align
to
that
one,
multiple
charts
that
are
based
on
their
get
get
ladder
rails
code
base
they
get
like
a
sha,
they
just
take
the
same
version,
so
it'll
go
and
look
at
the
rails,
codebase
and
say:
okay,
actually
what
that
version?
This
is
the
image
I'm
going
to
get,
which
is
based
off
of
that
version.
E
E
D
D
So
the
reason
why
they're
not
is
that
we
have
two
currently
introduced
breaking
changes
in
the
charts
repository
more
frequently
than
we're
allowed
bump.
The
major
version
in
gitlab
at
the
moment,
so,
for
example,
12.7
will
be
a
Mike
will
be
Version
three
of
the
charts
we're
doing
a
major
update,
yeah.
E
Yeah
I
guess
I
guess
you
know
where
this
falls
apart
is
when
we
have
a
charts,
specific
change
and
we
have
an
omnibus,
specific
change
that
doesn't
affect
the
underlying
component
versions
right
because
then
you're
going
to
diverge
between
charts
and
omnibus,
like
you
know,
you'll
have
different
jaws
for
the
same
version
of
rails.
That
is
contained.
We.
B
E
B
E
B
E
I
wonder
if
that
will
ever
happen,
I
think
you
know
we
can
always
think
of
a
case
where
we
have
a
critical
regression
in
charts.
That
is
only
in
charts
and
not
in
any
of
the
applications
right,
and
that
would
require
a
new
point
to
release
a
new
patch
release,
and
then
we
would
issue
that
for
charts,
and
then
we
wouldn't
bump
at
Romney
bus
and
then
the
next
release.
What
would
we
do
skip
that
version
if
they
were
doing
in
lockstep?
Or
would
we
issue
an
omnibus?
D
D
D
Should
be
so
so
I
think
in
terms
of
our
worries
more
about
the
major
version
changes,
so
we
want
to
line
up
like
the
the
small
patches.
We
already
have
this
problem
in
omnibus,
where
sometimes
an
omnibus
specific
change
is
needed,
and
we
make
you
guys
just
patch
everything
right
like
the
whole
release.
It's
a
new
patch
yeah.
E
D
E
E
E
I've
been
thinking
about
it
and
I,
don't
know
what
what
the
right
thing
to
do
is
whether
we
should
and
have
them
move
independently
of
each
other.
The
market
have
to
marketing
releases,
one
from
omnibus
one
for
charts.
I
have
one
marketing
release
where
sometimes
omnibus
will
skip
a
patch
or
charts
will
skip
a
patch.
It's
yeah.
D
So
there
yeah
we
could
continue
to
explore
so
omnibus,
for
example,
does
have
added
additional
version
information
that
we
never
use
anymore
for
revision,
that
if
we
built
it
into
the
release
tools,
we
could
start
making
use
of
that.
We
could
also
I
think
we
can
actually
do
the
same
for
charts
as
well.
If
we
did
want
to
add
the
additional
revision
on
top
of
the
patch.
D
A
C
Cause
actually
complexity
for
customers,
I
mean
I,
think
it
depends
on
how
often
we're
going
to
see
this
happen
like
to
have
the
case
where
we
need
to
bump
something
from
you
know,
like
one
person
like
have
a
release,
it's
only
an
omnibus
relation
or
only
a
charge,
release
I.
Think
we've
done
it
before
frowny
bust,
but
maybe
I
can
think
of
like
twice
in
like
three
years.
Something
like
that.
Maybe
one.
E
C
C
And
so
so,
Auto
employs
a
different
animal.
Like
I
think
you
know
it
depends
on
how
many
burgeoning
front
of
employee,
but
if
we
go
like
the
shower
or
something
like
that,
you
know
we
can't
I'm
thinking.
My
guy
feels
a
month
is
about,
as
often
as
we
can
tag
a
self-managed
release
for
like
our
customers.
E
C
C
E
Well,
in
that
case,
I
think
we
should
just
try
to
keep
them
in
lockstep
for
official
releases
patch
releases
and
in
worst
case
is
that
we
have
like
an
omnibus
bill.
That's
a
no
op,
you
know
that's
the
same
as
the
previous
one,
but
maybe
we
can
cross
that
bridge,
but
it
happens.
I
don't
know.
Maybe
it.
A
Next
steps
for
me,
I'm
gonna,
write
up
a
review
of
this
meeting
in
the
epic.
A
big
number
125
and
I'm
gonna
make
sure
I've
got
all
the
issues
aligned
with
what
we've
stated
today.
I
think
we're
already
on
a
good
path.
I've
got
a
merge
request
that
should
create
stable
branches,
but
I
need
a
kind
of
revamp
that
alet
revamp
that
a
bit
so
it
targets,
auto,
deploy
branches
for
CNG
I'll,
create
issues
to
deal
with,
what's
necessary
to
create
the
workforce.
Arts.
D
A
D
D
D
D
D
So
I'll
either
fall
I'll
find
the
issue.
If
we
haven't
logged
on
I,
think
of
it,
we
might
or
I'll
create
one
to
do
kind
of
a
handoff
of
those
two
areas:
the
CNG
tagging
and
the
the
helm
tagging
so
yeah.
We
have
them
wrapped
and
they're
they're
still
go
to
sentry,
but
we
think
like
they
don't
break
the
release,
build
and
that's
because
we
didn't
want
to
when
we
first
put
it
in.
B
Okay,
just
want
to
point
this
out
because
I
just
realized,
as
I
was
reviewing
epic
125,
the
prior
discussion
from
the
beginning
of
November,
when
we
were
talking
about
how
the
pipeline
actually
functions.
John
described
like
this
is
where
you
were
asking
like.
Why
does
this
job
take
an
hour
or
something
Myron
pointed
out
that
at
some
point
in
the
future,
we
may
actually
want
to
split
the
CNG
completely
separated
and
let
let
those
actually
be
generated
by
their
originating
repositories.
B
This
aligns,
with
future
work
to
the
point
where
we
can
Auto
deploy
off
near
master
for
every
individual
component.
I,
don't
see
that
happening
before
13,
but
it's
possible,
and
that
is
further
work
to
getting
us
more
capable
of
doing
continuous
deployment,
because
right
now,
in
order
to
deploy
a
change
to
get
aliy,
you
actually
have
to
update
rails,
which
rails
then
triggers
the
pipeline
and
dip
up
above
the
bump
bump.
B
So
we're
also
back
to
this.
Let's
all
walk
up
on
the
rails
version
problem
which
john
jarvis
it
plays
in
the
same
problem,
so
just
want
to
throw
that
in
the
back
of
the
mind,
but
let's
not
be
too
concerned
about
perfect
LOC
stepping
when
it
comes
to
actual
release
release,
but
we
should
understand
where
that
target
is
going
in
six
months
to
a
year.
We.
A
Have
an
epoch
in
our
backlog
that
we've
graced
a
couple
of
times:
it's
that
big
113.
If
you
want
to
take
a
gander
in
it,
it's
not
very
well
titled,
but
it's
talking
about
how
we
could
basically
discuss
exactly
what
you
described
versioning
each
component
and
having
some
master
repository
that
contains
a
version
that
is
known
to
work
for
gitlab
across
the
board
and
we'll
build
off
of
that.