►
From YouTube: 2021-10-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).
A
A
Okay,
so
welcome
everyone.
This
is
the
monthly
delivery
team
ama,
so
we
are
responsible
for
deploying
and
releasing
to
doc,
to
gitlab.com
and
also
to
our
self-managed
users,
so
here
to
answer
any
questions
that
anyone
has
and
we
have
just
alessio-
I
think
so
far
from
the
team,
so
he'll
be
taking
most
of
your
questions
today,
but
greg.
Thank
you
for
having
the
first
question.
Please
kick
us
off.
B
Right
thanks
amy,
so
a
little
bit
of
context.
Yesterday
I
was
trying
to
track
down
a
strange
behavior
on
gitlab.com
sas
where
it
seemed.
B
If
you
were
to
try
and
import
a
project
from
a
gitlab
export,
it
would
immediately
404
and
it
appears
it
was
because
the
namespace
id
was
being
set
to
undefined
instead
of
actually
being
set
to
the
proper
number,
and
so
I
was
trying
to
reproduce
this
hunt
down
where
the
code
change
occurred
and
test
on
self
manage,
and
I
found,
as
of
yesterday,
the
gitlab.com
sas
is
running
14.4.03.
B
And
that's:
there's:
it's
released
in
docker
image
form
and
linux
package
form.
I'm
just
wondering
how
do
the
semantic
versions
of
gitlab.com
relate
to
our
nightly
release
version
numbers.
C
Yeah,
okay,
I'll
give
it
a
try,
there's
so
yeah.
This
is
a
great
question.
So,
first
of
all,
the
nightly
release
package
that
we
are
running
on
dev
is
something
that
are
not
strictly
owned
by
our
team,
so
they
just
get
built
overnight
and
get
installed
on
those
machines.
So
we
have
less
control
and
less
context
around
that
one.
But
I
can
tell
you
how
you
where
you
can
find
the
right
code
for
what
is
running
on
github.com
production
or
staging,
so
this
is
kind
of
tricky.
C
We
were
working
through
this
actually
this
week,
so
basically
we
we
create
several
auto
deploy
branches
each
day
from
the
master
branch
of
gitlab
gitlab
repository.
What
we,
when
we
talk
internally,
the
those
auto
employee
branch.
We
are
using
a
version
which
is
a
major
minor,
so
the
basically
the
upcoming
milestone
the
milestone
we
are
in
so
you.
C
Now
this
is
true
if
you,
if
you
are
looking
at
the
tags
in
the
project,
but
if
you
look
at
the
package
version
that
you
can
see
on
the
help
page,
I
just
noticed
that
you
just
see
dot
zero
pre
because
it's
unreleased.
Basically
what
what
what
happens
there
is
that
we
in
on
github.com,
we
are
running
unreleased
versions,
so
the
only
useful
information
you
have
right
there
is
the
shop.
C
Now
there
are
several
chat.
Ups
commands
that
you
can
run
to
actually
get
the
what
is
actually
running
and
github.com
and
gives
you
links
to
the
auto
deploy
branches
where
you
can
find
that
specific
commit
just
for
information,
because
if
you
are
trying
to
reproduce
something-
and
you
want
that
specific
commit,
it
could
happen
that
this
commit
lives
only
on
the
security
branches,
because
we,
because
of
the
nature
of
security
releases,
we
don't
run
out
of
deploy.
We
don't
create
auto,
deploy
attacks
on
the
canonical
repositories.
C
A
I
was
trying
to
find
the
documentation
as
well.
I
believe
we
have
this
all
documented,
so
I'll
dig
those
out
with
how
we
do
the
tagging
and
the
the
commands
and
things
that
you
can
use
to
help
I'll
put
this
one
in.
B
Yeah
I
did
find
that
link
to
the
sha
on
the
help
page
was
really
helpful
in
in
finding
which
yeah
what
code
we're
running,
and
this
case
it
actually
was
not
the
code
at
all.
It
was
a
feature
flag,
so
just
just
good
to
know
for
next
time.
A
Excellent
great
thanks
so
much
for
asking
that
greg.
Does
anybody
here
we
go.
A
Excellent,
so
chris
welcome,
would
you
like
to
verbalize
yeah.
D
Sure,
sorry,
I
was
gonna
turn
it
on
mute
here.
Hi
everyone
yeah,
I'm
relatively
new
to
get
lab
about
a
month
in
pee
on
the
release
team
and
just
curious.
I've
been
meaning
to
talk
to
your
team
you're.
Definitely
on
my
list
to
better
understand
how
you
currently
use
gitlab
and
you
know
potentially
figure
out
what
what
else
we
can
build
in
the
stage.
D
C
The
the
main
reason
why
we
have
problems
with
the
feature
with
the
release
features
is
that
most
of
them
are
designed
to
be
working
on
a
repository
and
having
just
one
repository
to
track
stuff.
This
is
not
how
we
operate,
because
we
have
gitlab
rates
code
based
and
we
have
armanibus
for
packaging
the
linux
images,
but
then
we
have
cng
images
for
docker
helm
for
charts.
C
We
have
gisly,
we
have
several
components
that
have
their
own
repositories,
so
we
ended
up
having
all
this
information
in
our
release,
tools,
project
and
from
there.
We
are
doing
api
calls
for
for
reasons.
When
we
track
a
release,
we
have
to
figure
out
in
each
project
with
which
which
commit
are
we
deploying
I?
We
did
we
deployed
and
send
api
calls
to
every
project
saying
we
deployed
this
in
this
environment
and
in
this
in
this
environment,
and
this
is
an
environment.
C
So
that's
that's
the
main
problem
that
we
have,
that
there's
no
concept
of
what
we
said
that
product
version
so
having
a
product
that
is
made
of
several
sub
projects,
and
then
you
say
I
deployed
this,
and
this
is
made
of
this
component
on
those
versions.
There's
no
such
thing
so
yeah,
that's
the
main
takeaway.
Thank
you.
A
And
I
think,
there's
a
couple
which
we've
kind
of
been
talking
about
a
little
bit
and
we're
perhaps
have
the
same
kind
of
concepts
in
mind,
but
we
don't
use
the
kind
of
official
gitlab
versions
yet,
but
I
hope
in
the
future
we
will
so
the
dora
four
metrics
is
one
where
we
track
our
releases
using
mean
time
to
production.
A
So
at
the
moment,
that's
all
in
si
sense
and
we're
tracking
we're
counting
on
mrs,
but
we
hope
in
the
future
that
actually
we'd
be
able
to
properly
adopt
for
dora
4
and
have
everything
but
again
because
of
our
multiple
repos.
It's
it's
not
sort
of
a
straightforward
switch
for
us
and
any
other
big
one.
We
have
is
rollbacks,
so
we
have
been
watching
the
rollbacks
feature
with
interest.
A
We
have
rollbacks
in
release
tools
and
we
we
run
rollbacks,
but
we
have
a
slightly
more
complicated
use
case,
which
is
is
why
we
haven't
adopted
the
kind
of
official
release
version
yet,
and
the
reason
is
because
we
we
still
do
a
forward
deployment
as
the
product
is
built
to
support,
but
on
gitlab.com
we
actually
have
to
reverse
the
pipeline.
So
we
can't
just
rerun
the
same
pipeline.
We
actually
run
a
different
deployment
pipeline
where
we
flip
the
order
of
the
jobs
to
safely
roll
back
on
gitlab.com.
A
A
Okay
thanks
so
much
for
asking.
Does
anybody
else
have
a
question.
E
E
And
it
doesn't
have
to
be,
you
could
use
like
say
just
ubuntu
as
an
example
or
whatever,
but
I'm
curious
about
how
how
it's
built
and
then
the
testing
of
the
package
itself
to
make
sure
that
everything
was
completed
properly.
A
So
this
is
very
much
owned
by
the
distribution
team,
so
they
they
build
all
the
packages
for
their
different
environments
and
test
those
and
then
once
the
packages
are
kind
of
in
existence,
then
delivery
does
the
work
to
kind
of
coordinate
the
actual
deployments
out.
So
unless
or
less
here
happens
to
have
some
specialist
knowledge,
I
think
do
you.
I
think
this
is
just.
C
Give
some
hints
but
yeah,
so
we
basically
triggered
those
projects
that
we
called
packagers
to
create
a
package
with
the
information
that
we
provide
them,
which
means
a
sha
of
various
components,
and
then
we
wait
for
them
to
do
their
job
and
then
we,
as
amy
mentioned
we,
we
continue
the
delivery
from
there.
So
I
can
tell
you
that
we
have
two
packages:
one
is
cng
for
docker
images
and
the
other
one
is
omnibus
for
linux
images,
the
one
so
dab,
rpm
package
this
or
this
type
of
packages.
C
So
in
that
case,
basically,
the
packages
are
built
with
they're
written
with
this
omnibus
gitlab,
which
is
a
fork
of
omnibus
which
comes
from
the
chef
project.
I
think-
and
basically
it's
a
it's
a
it's
a
recipe
system.
You've
the
recipe
are
written
in
ruby
they
run
on.
They
create
a
package
that
just
run
check
the
status
of
the
system,
update
what
changed
and
installed
packages
change,
configuration
files
and
things
like
that.
They,
the
recipe
themselves,
have
testing
suits.
F
A
What
I'll
do
is
we
can
pass
this
over
to
distribution
marks
so
that
we
can
ask
for
their
input
and
they're,
unfortunately,
not
on
the
call
today,
but
we
can
certainly
ask
them
to
to
follow
up
and
build
out
on
our
slightly
lightweight
answer.
A
Nope;
okay,
in
which
case,
thank
you
all
for
joining
us
today
and
ask
all
the
questions
and
please
feel
free
to
come
and
chat
to
us
in
ge
delivery
or
releases
channel.
If
you
have
really
specific
questions,
otherwise,
thank
you
very
much
and
enjoy
the
rest
of
your
day.