►
From YouTube: 2023-09-13 AMA about GitLab releases
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).
B
Hello
I'm,
just
gonna,
wait
a
few
seconds
before
I
start.
Hopefully
save
some
delivery.
People
have
joined
building
somewhere.
Some
questions.
B
But
I'll
go
ahead
and
get
started
so
welcome
everyone
thanks
for
joining
us.
This
is
our
monthly
delivery
group
AMA.
So
delivery
is
deploying
changes.com
and
we
are
preparing
and
Publishing
the
releases
to
our
self-managed
users
as
well.
If
you
have
any
questions,
please
drop
them
in
the
agenda
and
I
will
go
ahead
and
get
started.
We
are
joined
by
various
people
from
delivery
group,
so
hopefully
you'll
be
able
to
answer
any
questions
and
John
has
a
question
he's
not
on
the
call,
but
he's
left
us
an
async
question.
B
B
Do
we
have
anyone
on
the
call
who
would
like
to
give
us
a
brief
summary
of
of
some
of
the
pain
points
and
also
like
I,
guess
considerations.
We
take
into
account
when
we
are
deploying
Italy.
B
B
D
Well,
I
hope
so
I
hope
so
so
for
the
last
security
releases
involving
it
I.
Remember
that
it
has
to
be
careful
not
to
leak
the
version
to
the
public,
because
we
get
some
coordination
with
the
git
team
like
hey.
D
There
is
this
release
date
and
we
need
to
coordinate
the
Embargo
date
with
both
the
git
team
and
the
gitlab
team,
and
that
creates
a
bit
of
hard
work
because
we
need
to
prepare
the
version
from
our
site
and
deploy
it
to
gitlab.com
without
leaking
them
before
the
Embargo
date
leads
on
the
git
side.
So
that
is
one
problem.
D
Another
one
is
that
we
need
to
do
some.
Preparations
in
our
servers
I
believe
to
actually
confirm
that
we
are
running
an
undisclosed
version
from
git.
D
B
I
think
we
have
an
interesting.
We
have
a
few
interesting
dependencies
and
sort
of
critical
ordering
for
a
regular
deployment
of
Italy,
and
then
it's
made
a
little
bit
more
significant
when
we're
doing
any
kind
of
security
release.
So
in
a
regular
deployment
of
of
gitly,
we
have
got
two
kind
of
firm
release
methods
for
ghetto.
We
have
the
gitly
gem,
which
is
entirely
owned
by
the
Italy
team
and
published
new
versions
go
out,
and
we
also
have
the
gitly
deployment.
B
That's
part
of
our.com
deployment
that
has
quite
a
significant
version
dependency,
so
we
must
deploy
that
and
roll
it
back.
In
about
specific
order
to
manage
the
dependencies
and
because
of
the
gem
and
the
Italy
deployments,
we
also
have
kind
of
different
versioning
dependencies
that
come
in
so
I
think
it
gets
difficult
around
security
releases.
When
we
need
to
update
the
gem,
we
also
need
to
update
the
gitly
we're
using
for.com
and
we
can't,
as
Myra
mentioned
about
the
embargoing,
we
can't
always
reveal
the
vulnerability
ahead
of
time.
So
it's
the.
B
How
do
we
control
that
rollout
to
get
all
of
the
versions
updated
and
yeah
I?
Think
it's
one
like
Sam
I
know:
you've
been
kind
of
talking
a
bit
with
gitly
team
already
about
improving
processes,
but
like
definitely
something
we
we
would
love
to
be
able
to
to
improve
on
I
believe
there
are
some
issues
already
but
I
know
it's
not
something
a
delivery.
It's
managed
to
get
capacity
to
to
iterate
on
so
far.
D
I
think
another
one
of
those
issues
was
to
try
to
document
all
the
environment
variables
that
we
were
using
because
since
we
were
required
to
use
a
different
version,
that
was
in
public
that
was
built
in
our
like
in
a
Repose,
some
environment
variables
that
need
to
be
modified
in
our
deployer
projects.
And
it
was
a
mess
at
some
point
because
we
didn't
know
which
point
was
referencing.
So
I
think
there
is
an
issue
about
documenting
that
process
somewhere.
B
Deployments
together
have
an
interesting
process
as
well,
because
in
many
ways
they
are
using
our
most
automated
deployment
method
and
that,
unlike
for
other
gitlab
components,
what
we
have
is
an
automated
creation
of
an
MR
which
the
GitHub,
oh,
no,
sorry,
the
release
bot
creates
an
MR
and
it
gets
approved,
and
then
it
should
sort
of
set
to
merge
when
the
pipeline
succeeds
and
it
gets
pulled
into
Auto
deploys
automatically.
So
in
a
good
day,
changes
Merchant
gitly
get
automatically
just
pulled
in
to
our
github.com
deployments.
B
We
do
have
two
pain
points
around
them.
One
is,
there
is
something
which
is
some
kind
of
bug
in
a
product
or
the
sum
thing
I
don't
think
we
ever
got
further
than
thing,
which
can
mean
that
once
you've
set
a
pipeline
to
succeed,
it
doesn't
always
merge
and
the
belief
seems
that
the
if
something
interrupts
it
it
will
be
passing
and
ready
to
go
but
not
merged.
B
That's
something
which
we
see
on
occasion,
which
means
that
new
gettily
changes
just
don't
get
pulled
in
when
they
when
they
should
be,
and
then
I
need
manual
intervention,
the
other
one
that
we
have
is
flaky
tests,
so
sometimes
giddly
changes
get
merged
and
tests
fail,
and
that
means
that
also
the
automatic
pulling
in.
So
there
are
a
couple
of
points
where
what
should
be
a
fully
hands-off
process
ends
up
not
being,
and
that
can
be
quite
disruptive.
E
E
Guess
the
only
interaction
I
have
with
releases
that
I'm
aware
of
is
we
have
a
very
manual
process
to
get
the
elasticsearch
indexer
updated
I,
don't
like
the
way
that
works,
because
it's
still
very
manual
there's
a
lot
of
manual,
Mr
creation
and
tagging
and
stuff
that
feels
like
it
shouldn't
be
that
hard,
but
that
I
don't
necessarily
want
that
for
soup,
but
I
yeah,
I,
guess
I'm
just
a
little.
How
lost
about
what
steps
we
should
take
and
I
can
link
the
issue
and
document
for
anyone
that.
B
Yeah,
this
is
a
great
question,
so
Zoot
is
using
our
shops.
So
at
the
moment
you
get
your
rollouts
on
a
Monday.
We
do
a
weekly
chopped
bump
with
the
get
up
chart
bump,
and
that
is
a
semi-automated
process.
We
have
running
in
delivery,
so
we
get
the
Mr
created.
Then
somebody
in
delivery
needs
to
manually
review
that
and
we
merge
it
and
roll
it
out
through
the
different
environments.
B
Now
we
have
a
better
process,
but
still
not
brilliant.
We
have
a
better
process
for
something
like
container
registry,
which
is
a
similar
type
of
component
still
very
manual
and
in
an
Ideal
World.
We
would
automate
it
and
pull
it
into
our
gitlab.com
Auto
deployments,
but
again
capacity
is
making
that
our
main
blocker
there,
so
the
Big
Challenge
we
have
with
making
Zoot
more
frequent
is
when
we
update
the
chart.
It
affects
all
our
components.
B
So
Graham
came
back
with.
There
are
sort
of
two
ways
we
can
do
this
so
either.
You
can
essentially
adopt
the
manual
process
that
teams
like
package
are
using
with
container
registry.
It
will
still
be
a
bit
manual.
You'll
still
need
to
go
through
some
steps,
but
the
end
result
is
that
you
will
get
a
process
where
you
can
create
a
merge
request
which
just
bumps
your
zooped
version.
You
would
still
need
somebody
to
review
and
merge
that,
but
that's
a
little
bit
easier.
B
It's
a
little
bit
less
risky
and
generally
most
sres
are
kind
of
comfortable
to
do
that
process.
So
things
move
a
bit
faster
or
we
can
do
more
frequent
chart
bumps.
That
is
probably
not
going
to
be
like
consistently
done.
That
will
depend
a
bit
on
delivery
work,
so
you
get
weekly.
We
may
be
able
to
do
them
more
frequently,
but
it
will
a
bit
depend
on
on
who's
available
to
do
those
things.
B
So
in
an
Ideal
World
we
would
have
a
process
where
you
would
be
set
up
more
like
Italy,
so
you
would
actually
get
the
automated
version
bumping
and
things
would
just
be
pulled
in,
but.
E
B
Not
now,
unfortunately,
we're
not
self-serve
on
these
things
at
the
moment,
so
we
would
have
to
prioritize
some
delivery
time
to
to
get
that
implemented.
E
For
this,
the
one
that
you're
recommending
I
did
read
that
I.
Guess
that
my
question
around
going
that
route
is
there
going
to
be?
If
we
do
that
and
override
the
container
version
of
Zoot,
does
the
chart
book
still
have
to
happen.
B
I'm,
not
sure
I
mean
it
would
still
have
to
happen.
I
think
you
would
still
I
think
you
would
get
your
changes.
I
think
they
would
be
visible,
but
I'm
not
totally
sure
I'd
maybe
have
to
chat
with
Grant,
okay,
but
I
believe
if
it's.
If,
if
what
he's
proposing
is
the
same
as
what
we're
doing
for
the
container
registry,
you
would
you
would
get
your
version
visible
and
you'd
be
able
to
see
the
things.
B
E
Okay,
I
appreciate
the
the
chat
about
it.
It's
just
this
stuff's
all
a
little
new
to
me
so
I
and
CZ
mentioned
that
this
call
is
happening
and
I
was
like
well,
that's
very
convenient,
so
I
guess
yeah
yeah.
We
can
see
maybe
there's
a
way
to
get
trained
up
on
the
process
asynchronously.
So
we
can
get
a
few
of
our
team
members
up
and
running
on
this.
That
would
be
great.
B
Sure,
let's
do
that
yeah,
let's
figure
out
what
we
would
need
to
give
you
I
I'll,
have
a
look
and
see
if
we've
got
any
docs
that
will
guide
you
on
this
and
then
we
could
just
sort
of
close
the
gaps
to
help
you
to
help.
You
do
that
and
then
you
can
just
like
pretty
much
update
as
often
as
you
need
to.
F
Oh
yeah
I
just
wanted
to
say
thank
you,
everyone
for
the
collaboration
on
the
release
date
change
to
the
third
Thursday.
It's
been
a
pleasure
getting
to
work
with
a
bunch
of
you
via
issues
and
epics,
but
I
haven't
actually
gotten
to
say
hi.
So
I
wanted
to
say
hello
and
thank
you
for
the
collaboration.
D
Now
yeah
the
the
Epic,
it
is
titled
with
draft
move
them
onto
release
date.
F
Yeah
I
just
removed
that
thank
you
for
catching
that
I
appreciate
that
okay
I
think
we've
been
just
operating
by
all
the
sub
sub
epics
and
issues
that
that
just
got
missed.
So
thank
you
very
much
for
that.
B
And
I
want
to
say
hi
Ian
and
thank
you
for
the
work
you're
doing
so,
for
people
who
don't
know
Ian
is
doing,
did
a
really
hard
job
for
the
date
change
of
coordinating
all
of
us
across
all
of
gitlab
to
get
all
the
different
pieces
in
place
so
appreciate
all
of
the
the
work
that's
going
into
that
in.
F
Yeah,
it's
a
it's
a!
It
absolutely
takes
a
village,
and
this
is
a
group
effort
and
I
think
the
outcome
is
better
for
the,
especially
from
the
perspective
of
not
having
team
members
needing
to
work
on
weekends
or
feeling
like
they
need
to
work
on
weekends.
So
I'm
excited
about
that.
B
D
D
So
I
got
it,
I
got
it
so
as
a
response
to
the
release
date.
Moving
from
being
the
22nd
to
the
third
Thursday
of
each
month,
we
have
adopted
the
release,
tools
and
processes
to
comply
with
this
date,
and
basically,
we
adapted
our
tooling
the
release,
tooling
the
deployments
and
everything
to
make
sure
that
we
are
ready
to
release
our
versions
on
the
third
Thursday
of
each
month
and
also
as
an
aside,
that
implied
preparing
a
very
cool
gem
that
calculates
the
third
Thursday
for
us.
D
So
we
don't
have
to
calculate
it
manually,
because
thinking
like
thinking
of
the
22nd
date
is
very
easy
for
us,
because
we
know
this
is
a
hard
number,
but
calculating
the
third
Thursday
of
each
month
is
a
relative
date
and
it
is
hard
for
us.
So
we
also
came
up
with
a
gem
that
is
going
to
be
the
single
source
of
Truth
for
releases
informations.
It
all
not
only
calculates
the
upcoming
releases.
D
It
also
tells
you
what
is
the
active
version,
the
current
version
and
the
versions
that
are
inside
the
maintenance
policy,
so
that
is
very
cool.
We
are
going
to
do
an
announcement.
Very
soon
about
these
changes
to
make
everyone
aware
of
what
is
coming
and
the
change
is
actually
going
to
be
present,
starting
with
the
16.6
release,
which
is
are
going
to
be
on
November
so
exciting
times.
B
Absolutely
thanks
for
that
so
yeah
we're
hoping
to.
We
have
all
the
pretty
much
pieces
done
as
Maya
mentioned.
We
have
another
epic
that
we
will
bring
into
progress
on
the
23rd
of
October
so
that
we
can
just
make
sure
we
watch
all
of
the
delivery
pieces
closely
over
that
first
Milestone
and
make
sure
we
get
all
the
permissions
and
issues
and
all
of
the
little
bits
and
pieces
happening
as
we
expect
them.
B
So
yeah,
exciting,
exciting
progress
and
great
work
for
everyone
who
worked
on
that
one
and
Myra
for
driing
the
Epic
as
well.
A
B
But
it
should
be
less
tip,
though,
because
it
will
mean
in
in
November
the
the
release
date
is
the
16th
I
believe.
B
A
I'm
curious
about:
are
there
any
quality
of
life
improvements
that
you
want
to
highlight
in
the
last
you
know
month
or
two
other
than
obviously
moving
release
date,
but
that
hasn't
quite
happened
yet.
B
I
think
the
other
one
I
would
highlight
is
the
work
that
Steve
you've
just
wrapped
up
on
automating
parts
of
the
security
release.
Do
you
want
to
give
us
a
bit
of
a
overview.
G
Yeah
you
mean
the
the
work
that
we're
currently
working
on
or
some
of
the
automations.
The.
G
Yeah,
so
we've
made
a
lot
of
improvements,
automating
our
various
well.
We
started
with
the
security
release
and
so
we've
started
moving.
G
Instead
of
we
have
this
big
checklist
issue
that
we
just
worked
through
the
checklist
every
single
month
and
there's
I
think
there
was
80
some
items
on
the
list
and
we
started
going
through
and
automating
those
items
into
a
pipeline,
and
so
now,
instead
of
working
through
the
list,
we
just
go
and
click
Start
on
the
pipeline,
and
it
does
a
lot
of
those
different
tasks
for
us
with
the
eventual
goal
of
automating,
even
more
and
more
as
we
go
along.
G
But
what
we've
been
able
to
do
is
take
sort
of
the
initial
steps
of
the
security
release,
which
is
usually
like
the
first
day's
work,
and
then
these
steps,
right
after
the
release,
all
the
different
cleanup
and
resyncing
and
we've
moved
that
into
pipelines,
essentially
taking
it
down
from
you
know,
sometimes
an
hour
or
more
of
time
to
being.
You
know,
just
click
it.
It
runs
in
a
minute
or
two
and
then
spits
out
some
results
in
slack,
and
so
that's
been
really
nice
for
release
managers.
G
B
And
I
think
for
me,
this
one
was
really
exciting,
because
pretty
much
I
think
the
whole
time
I've
been
at
get
lab.
Our
releases
have
been
fairly
similar.
We've
had
a
checklist
of
tasks
that
we
go
through
to
get
a
release
out
the
door,
so
this
has
been
really
exciting,
because
this
is
our
sort
of
shown
us
a
path
that
looks
like
it
already
help
us
in
terms
of
actually
automating
a
lot
of
these
steps.
So
I
think
we've
already
made
a
little
bit
of
a
progress
on
the
monthly
release.
Prep.
B
A
B
Yeah
I
appreciate
it
thanks,
Dan,
fantastic
well,
in
which
case
thank
you.
Everyone
for
joining
and
thanks
to
everyone
who
asked
us
a
question
really
great
to
see
you
all
and
hopefully
we'll
see
you
next
month,
have
a
good
rest
of
your
day.
Thanks.