►
From YouTube: Run through creating a GitLab patch release
Description
Marin Jankovski recorded an overview of work done when creating a GitLab patch release.
Resources used:
Release handbook page: https://about.gitlab.com/handbook/engineering/releases/
Patch release docs: https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md
12.6.3 release issue https://gitlab.com/gitlab-org/release/tasks/issues/1142
A
Hello:
everyone,
my
name-
is
marina
and
Kowski,
and
I'm
a
senior
engineering
manager
in
the
infrastructure
department
today
I'm
going
to
explain
how
the
delivery
team
creates
patch
releases
a
specific
type
of
release
in
our
release.
Schedule
for
all
of
the
information
about
types
of
releases
that
we
have.
You
can
take
a
look
at
you
can
find
it
that
our
engineering
releases
handbook
page
where
we
have
a
clear
distinction
between
two
types
of
workflows
that
are
very
much
connected.
A
One
of
them
is
self-managed
release
and
the
other
one
our
release
is
related
to
github.com.
So,
as
I
mentioned
today,
I'm
going
to
be
talking
about
preparing
a
self-managed
release.
More
specifically,
a
patch
release
for
our
previous
monthly
released
version.
I
will
guide
you
through
the
documentation
that
we
have,
but
also
to
the
commands
that
are
listed
and
I'll
attempt
to
explain
the
purpose
behind
each
and
every
one
of
them.
A
A
Today
we
will
create
a
new
patch
release
and
the
reason
for
that
is,
we
have
a
number
of
bug
fixes
ready
to
go
and
the
way
release
managers
decides
to
create
a
new
patch
release
is
obviously
depending
on
demand
that
demand
might
come
from
customers.
It
can
come
from
developers,
but
periodically
release
managers
will
also
check
for
or
a
specific
label
that
developers
use
to
indicate
that
a
certain
release
is
ready.
A
This
label
is
called
peek
into
and
then
the
version
number-
and
in
our
case
we
are
looking
for
picking
to
12.6,
because
this
is
the
release
we
are
targeting.
As
you
can
see
here,
we
have
some
five
open,
merge
requests
with
this
label,
however,
given
that
they
are
not
ready,
yet
we
will
not
be
including
them
most
likely.
We
do
have
ten
merged
merge,
merge
request
with
picking
two
label,
which
means
that
we
have
enough
bugfixes,
ready
of
various
priority
to
send
out
to
send
fixes
to
our
customers.
A
This
is
a
place
where
all
the
developers
and
everyone
else
who
is
interested
can
interact
with
release
managers,
delivery,
team
on
any
questions
related
to
releases
by
executing
the
Chatham's
command.
A
number
of
things
are
going
to
happen.
The
reason
we
are
using
a
chat,
ops
command
is
we
have
automated
a
number
of
such
as
preparing
the
release,
issues,
preparing
the
actionable
items
that
we
have
in
the
release,
issues
and
so
on.
It
also
allows
us
to
do
a
couple
of
other
things
that
I
will
show
later
on.
A
For
now,
let's
go
to
the
job
that
the
chat
UPS
created,
so
we
use
chat
ups
to
trigger
our
builds
inside
of
our
release
tools,
project
release
tools
is
a
project,
a
public
one
that
is
there
as
an
Orchestrator
of
all
of
our
releases.
So,
as
you
can
see
right
now,
what
is
happening
is
we
triggered
the
build
that
is
now
creating
all
the
related
items
that
we
need
for
the
specific
release.
So
if
I
click
on
release
1263,
you
will
see
that
the
issue
is
created
in
our
release.
A
Slash
tasks,
project
tasks
is
a
project
that
we
use
for
general
release
tasks,
as
the
name
says,
meaning
we
use
this
project
to
orchestrate
our
release,
but
also
we
have
QA
issues
that
are
created
and
so
on,
and
so
on.
A
couple
of
things
worth
observing
here,
so
these
templates,
these
issue
templates
that
that
are
created
are
also
result,
is
residing
in
a
release
tools,
project
and
we
have
a
couple
of
things
to
go
through
this
issue.
A
That
for
any
12.6
related
release,
we
have
these
three
release
managers
assigned
in
the
issue.
If
you
check
here
that
actually
matches
so
the
command
worked.
Well,
we
have
a
due
date
also
set.
This
is
an
arbitrary
dates,
just
used
as
a
reminder
in
cases
where
something
delays
a
release.
We
we
just
use
it
as
a
guideline
there,
and
then
we
have
a
number
of
tasks
in
the
release
issue.
So
the
release
issue
has
a
check
check
boxes
here.
A
A
A
Nothing
really
too
interesting
to
note
here,
apart
from
the
fact
that
assignee
is
a
release,
bot
the
same
bot,
that
creates
it's
the
issue
and
is
executing
all
of
our
tasks
and
a
short
summary
of
what
is
going
to
actually
happen
when
this
merge
request
is
being
prepared
and
as
you
can
see
here,
we
are
targeting
our
stable
branch
rather
than
a
master
branch,
which
is
the
general
workflow
that
everyone
users.
So
the
reason
for
this
is
our
stable
branch
indicates
a
branching
in
history.
A
A
This
stable
branch
is
tied
to
another
event,
and
this
is
specifically
related
to
get
lab
comm
releases.
We
only
create
a
release
out
of
a
branch
that
has
been
deployed
to
get
lab
calm.
We
call
these
branches
auto
deploy,
but
those
branches
are
created
from
master
the
same
way.
Other
development
workflows
function,
so
our
stable
branch
that
we
saw
here,
twelve
six,
stable,
stable
EE,
is
created
from
the
auto
deploy
branch
that
is
currently
active
on
github.com
at
the
time
of
creation
of
the
release.
A
A
A
All
right
going
further
and
there
are
a
couple
of
others,
other
items
that
I'd
like
to
highlight
for
any
monthly
release.
We
also
create
a
channel
named
F
underscore
release
underscore
and
then
the
version
of
the
race
F
in
this
name,
branching
name
means
feature,
and
this
is
a
naming
we
use
for
general
short-lived
branches
inside
of
our
company.
A
A
Show
what
kind
of
actions
day-to-day
release
managers
are
doing?
First
of
one
first,
one
that
I'd
like
to
highlight
is
related
strictly
to
github.com.
This
is
not
really
important
for
the
patch
release,
because
this
uses
a
different
workflow,
but
it
is
important
to
note
that
we
have
two
processes
very
frequently
overlapping
handled
by
the
same
release.
Managers.
We
are
in
a
new
cycle,
so
a
new
set
of
release
managers
is
handling
this
one,
but
more
often
than
not
the
same.
A
Release
managers
will
also
have
to
ensure
that
github
will
come
in
all
the
environments
of
interest
are
in
the
consistent
state.
As
you
can
see
here,
we
have
the
version
that
we
are
targeting.
The
branch
name
of
the
currently
active,
auto
deploy
branch
that
was
created
out
of
master.
The
name
of
the
package
is
a
revision
that
we
are
deploying
and
so
on
and
so
on,
and
what
you
can
also
notice
here
is
that
canary
and
staging
currently
have
the
same
revision
deployed
and
production
has
a
different
one.
A
A
Another
interesting
command
here
is
checking
the
status
of
mirroring
we
use.
We
use
different
repositories
to
develop
different
depositories
for
security
development
and
also
different
repositories
for
builds
or
building
of
github
itself.
The
reasons
are
multiple
here.
First
of
all,
we
use
the
canonical
repositories,
as
you
can
see
here.
Those
are
public
repositories
open
to
everyone
which
is
in
line
with
the
way
we
work.
Those
repositories
are
automatically
mirrored
to
our
security
repositories.
A
Security
repositories
are
private,
Forks
of
the
canonical,
posit
or
ease.
The
reason
for
this
is
we
need
to
ensure
a
place
where
we
can
develop
these
fixes
in
private
to
ensure
that
we
keep
the
vulnerability
out
of
public
reach
until
we
are
ready
to
prepare
a
release,
and
then
we
also
have
those
items
mirrored
to
our
build
repositories
which
are,
on
a
completely
different
instance,
separate
from
github.com.
A
A
A
Zoom
is
now
my
blocking
my
window,
so
I
need
to
move
that
a
bit
you
all
right.
So
the
first
item
in
our
release,
issues
as
preparation,
mr,
should
be
already
created.
We
have
confirmed
that
these
items
are
created
so
for
now
we
are
going
to
close
them,
ensure
that
any
back
ports
targeting
are
merged,
they're,
stable
counterpart.
A
The
reasons
for
this
I'm
going
to
explain
very
shortly,
is,
if
check,
take
a
look
at
these
bridge
requests
here.
All
of
them
are
targeting
master
because
master
is
ahead
of
our
stable
branches.
So
as
soon
as
we
create
a
stable
branch,
master
diverges
from
it.
Sometimes
these
merge
request
won't
pick
cleanly
what
we
do
when
we
trigger
a
merge
command.
As
noted
in
the
release
issue,
this
specific
one,
what
we'll
end
up
doing
is
for
each
of
these
merge
requests.
A
We
are
going
to
use
the
API
to
cherry-pick
the
merge
commit
into
the
stable
branch,
thus
making
the
merge
request
ready
for
porting
to
stable
branch.
In
some
cases,
it
is
not
possible
to
get
these
items
cherry-picked
cleanly.
So
sometimes
we
have.
These
merge
requests
that
you
can
see
here
targeting
the
stable
branch.
In
this
case,
we
can
see
that
we
don't
have
any
merged,
merge
requests
with
the
picking
to
label,
which
means
these
items
are
already
handled
by
release
managers.
A
A
If
this
item
doesn't
pick
cleanly
by
us
from
this
section
by
us
triggering
this
command,
we
will
need
to
take
a
manual
action
emerges
manually
when
it
is
ready,
so
I'm
not
going
to
merge
them
yet
to
show
how
this
item
works,
then
we
come
this
command
into
our
chat
window
and
just
trigger
a
run.
Release
merge
command.
A
This
command
is
going
to
do
a
couple
of
things.
It
is
going
to
clone
the
repository
of
interest
in
this
case,
get
lab
a
rails,
repository
anomaly,
buzz
github
repository
and
it
is
going
to
fetch
the
branches
of
interest
and
it
is
going
to
then
trigger
the
jobs
that
will
pick
everything
that
is
necessary.
A
A
This
specific
item
that
I
mentioned,
like
the
manual
merge
request,
is
already
included
in
this
checklist,
so
we'll
need
to
ensure
that
this
template
is
updated
to
show
that
we
already
have
automatically
populated
this
item
and
we
don't
have
to
go
through
manually
process
for
manually
checking.
This
whole
thing.
A
A
Every
time
we
trigger
this
merge
task
to
give
the
release,
but
we'll
leave
a
message
with
some
details
of
what
has
actually
happened.
So
the
bot
left
a
comment
saying
that
the
merge
request
is
picked
into
our
preparation,
merge
request
and
it
will
that
preparation.
Merge
request
will
target
this
stable
branch
and
we
are
preparing
this
for
1263
EE
release.
A
Then
the
bot
also
removed
the
pic
into
stable,
indicating
that
this
merger
was
picked
cleanly
and
that
there
is
no
follow-up
action
to
take
for
this
specific
release,
which
means
that
we
will
most
likely
have
to
focus
well,
basically
on
none.
It
seems
that
everything
has
picked
cleanly
so
back
to
our
job
that
ran.
We
can
see
how
for
the
output
rather
of
items
that
we
just
baked.
A
A
Take
a
look
at
what
has
actually
happened
all
right
as
expected,
so
this
merge
request
is
the
the
reason
why
we
have
inside
of
the
release
issue.
This
specific
module
class
developer
rightly
so
expected
that
whatever
was
done
in
this
merge
request
won't
pick
cleanly
inside
of
the
stable
branch
and
they
prepared
this
backwards.
Merge
request
of
this
main
merge
aguas.
So
what
has
happened
here?
A
Github
release
bot
has
said
that
this
merge
request
cannot
be
picked
cleanly
and
will
need
a
manual
intervention.
It
also
gives
some
indication
to
the
developer
on
what
needs
to
happen
so
create
a
new
em,
are
targeting
the
source
branch
of
that
and
then
assign
to
release
managers
or
solve
the
conflicts
and
then
ensure
that
this
label
is
applied.
This
label
is
now
removed
from
get
ur.
A
From
this
specific
merge
request
indicating
that
we
can't
do
any
additional
act
action
and
we
won't
be
including
this
specific
merge
request
now,
given
that
we
actually
have
the
merge
request
already
prepared.
So
this
one
specific
this
specific
one,
there
are
two
things
we
can
do
here.
We
see
that
four
minutes
ago
there
was
an
action
taken
here.
I
will
have
to
check
what
actually
happened
there,
but
the
tests
are
running
here.
So
we
can't
really
do
much
with
this
specific
merge
request.
Yet
I'm
going
to
take
a
look
at
what
was
the
mention
here.
A
Alright
Urich
has
just
changed
the
description
to
ensure
that
we
are
aware
of
this
ongoing
thing
and
back
to
the
release
issue.
You
can
check
out
that
new
club
release
bot
has
actually
also
created
this
snippet
here
with
items
that
it
successfully
picked,
and
this
item
will
specifically
be
useful
for
us
when
we
end
up
creating
a
blog
post,
so
release
managers
that
then
can
just
copy
this
block
into
the
monthly
release
blog
post,
all
right
Larry.
Let
us
close
some
of
these
windows.
A
What
I'm
going
to
do
here,
specifically
with
this
merge
request,
that
is
targeting
the
stable
branch
I'm
going
to
change
the
target,
to
make
sure
that
we
are
targeting
the
same
preparation,
merge
request.
The
reason
why
developer
created,
merge
request
targeting
a
stable
branch
is
because
obviously
this
branch
didn't
exist
at
the
time.
So
with
this
I
can
just
say
safe.
We
are
targeting
a
different
branch.
A
Sign
this
to
myself,
there
is
some
opposing
information
there
and
I
think
I
want
to
make
sure
that,
because
I'm
handling
this
release,
I
am
the
one
responsible
for
it
all
right,
I
can't
do
much
with
this.
Until
it
passes,
we
won't
be
merging
the
merge
requests
into
a
preparation,
merge
request
until
this
specific
module
quest
passes.
So
in
the
meantime,
we
can
just
check
the
rest
of
the
output
here
and
we
don't
have
to
do
anything.
Release
managers
would
not
usually
look
at
this
output
here.
A
Release
managers
will
most
likely
look
at
this
to
make
sure
that
everything
is
merged,
and
this
specific
item
here
as
well
to
make
sure
that
there
is
no
open
begin
to
labeled
merge
requests.
The
only
thing
left
are
these
two
items
which,
unfortunately,
we
will
most
likely
omit
from
this
release.
Now,
with
this,
we
can
check
off
our
run,
release,
merge
item
and
I'm
going
to
check
off
these
items
as
well,
and
the
next
item
shown
here
is
says:
merge
the
preparation
branches.
A
Now
we
won't
be
merging
the
preparation
branches
yet
because
we
now
have
this
merge
request
containing
all
of
the
preparation
branches
with
release
but
again
leaving
a
comment.
Saying
I
think
these
merge
request
successfully.
This
one
failed.
We
already
know
why-
and
this
is
a
handy
information
for
release
managers
to
know
what
they
should
be
focusing
on.
Next,
there
are
11
commits
here
a
lot
of
changes
picked,
so
we
need
to
ensure
that
the
pipeline
passes
for
this
specific
branch.
Once
it
does
pass,
we
will
be
able
to
merge
and
continue
with
our
release.
A
A
When
we
are
ready
to
prepare
the
release,
as
our
release
issue
says
here,
we
will
merge
the
preparation
branches,
so
only
when
this
is
completely
green
release
manager
is
going
to
approve,
result,
working
progress,
status
and
merge
into
branches.
We
will
do
that
for
both
merger
classes,
both
for
Omnibus
and
for
for
get
Lobby
II.
A
So
in
this
case,
these
two
merge
requests
are
linked
here
and
release
managers
can
easily
go
and
just
make
sure
that
branches
are
merged,
because
we
didn't
have
anything
to
pick
for
this
specific
omnibus
release
for
twelve
six
table
most
likely.
We
are
just
going
to
close
this
merge
request
and
it
will
be
no
up
as.
A
When
we
ensure
that
the
bills
are
green-
and
there
is
a
reason
for
that,
if
we
tag
a
release
and
build
is
read
in
omnibus,
that
means
we
will
not
be
able
to
build
a
package
which
means
that
we
won't
be
able
to
build
a
specific
version
and
because
tagging
make
sure
that
we
we
use
the
specific
tag
in
all
of
the
repositories.
We
will
have
to
do
some
manual
work
and
we
would
rather
avoid
that
the
next
step
here
is
packaging.
Packaging
is
very
simple.
A
We
would
be
running
this
mirror
status
command
to
ensure
that
everything
is
green
and
passing.
We
do
have
this
manual
item
that
I
would
like
to
remove
here,
because
we
now
do
have
this
command
to
allow
us
to
see
the
mirroring
status,
and
with
that
we
would
be
running
this
command.
Fetch
run
release
tag.
So
let
us
take
a
look
at.
A
You
I
just
had
it
in
my
view.
There
we
go.
Let's
use
this
job,
so
even
though
it
failed,
we
know
why
it
failed.
We
failed
because
of
mirroring
that
was
broken
I'm,
going
to
run
you
through
the
job
that
actually
tags
the
builds.
What
happens
here?
A
couple
of
things
are
happening
in
the
background
preparing
repository,
we
start
with
our
get
lab
repositories
to
get
lebra's
repository.
A
This
command
will
fetch
the
repository
out
of
cache
and
then
update
the
necessary
remotes,
and
the
next
item
that
release
tools
will
do
is
it
will
compare
compiled
a
change
lock?
So
let
me
go
and
quickly
go
through
this
and
let's
check
the
stable
branch
to
see
how
this
currently
looks
foreign
specifically
for
12:6
release.
You
can
see
here
that
for
12
6
1
Alaska
was
the
one
preparing
the
release.
He
merged
the
preparation
branch
into
the
stable
branch.
So
this
is
what
we
all
end
up
doing.
A
If
you
check
once
we
tagged,
we
have
this
compiling
changelog
item
for
this
specific
version.
That
is
this
command
here
or
rather
commit
here.
So
there
is
no
specific
EE
related
feature
changed
in
this
release,
so
the
release
bot
inside
of
the
release
tools
obviously
have
to
release
those
commands.
We'll
just
leave
a
placeholder
saying
no
change.
The
next
one
is
specific,
is
applicable
to
every
edition
of
github,
and
it
shows
that
we
have
to
bug,
fixes
and
one
performance
fix,
and
then
it
also
links
to
the
merge
request.
We
also
see
3
deletions.
A
A
A
It
then
does
a
push
to
all
the
remotes
to
make
sure
that
we
are
on
time
with
pushes
and
not
depending
on
mirroring,
which
can
be
slightly
delayed,
and
then
it
goes
and
creates
a
tag
with
this
name.
So
on
top
of
this
version
commit
we
will
also
create
a
annotated
tag
and
that
will
also
be
synced
to
all
the
repositories.
Now
this
gets
repeated
for
multiple
other
repositories,
omnibus
github
package
repository
and
then
also
home
charts
repository
will
also
do
the
same
thing.
A
Github
see
is
the
next,
so
this
is
the
one
indicated
here
by
gillip
F
OSS.
The
reason
why
this
one
specifically
failed
was
like
I
said
here
because
of
the
mirroring
failure
we
have
since
resolved
this
issue,
so
we
won't
be
seeing
that
again,
but
there
is
nothing
else
really
interesting
here
to
indicate.
Apart
from
that,
the
same
way
the
github
ee
release
has
been
handled.
Eclipse,
ee
release
will
be
handled
as
well.
A
A
All
right,
we
have
created
a
lot
of
tax
all
right.
We
have
pushed
two
specific
versions
of
1261
here,
c
e
and
e
e
related.
This
will
independently
build
packages
for
community
edition
m
for
enterprise
edition,
given
that
we've
been
focused
on
the
enterprise
edition
or
the
main
repository
so
far.
Let's,
let's
take
a
look
at
that
nothing
unusual
here.
The
release
bot
has
created
a
tag
in
omnibus
that
could
synced
here
to
dev,
and
then
we
can
just
check
out
how
this
looks
inside
of
that
get
alert.
Org
inside
that
github
dot
org.
A
A
Well,
one
pipeline
is
running
on
a
tag
and
the
other
pipeline
is
running
on
a
stable
branch.
This
stable
branch
one
has
different
actions
than
the
tagged
one.
So
let's
take
a
look
at
the
tag,
one,
because
that
one
is
the
one
from
which
we
create
the
jobs
in
order
to
save
some
time
and
not
duplicate
the
the
same
work.
That
is
being
done
between
get
lab
and
omnibus
repositories.
A
We
wait
for
assets
to
be
built
inside
of
the
github
repository
where
production
assets
such
as
CSS
files,
JavaScript
images
and
so
on,
get
compiled
ready
for
production
consumption.
We
then
have
all
these
items
here
worth
going
through
really
quickly,
so
we
create
a
QA
image.
The
skewing
image
will
ultimately
be
used
to
automatically
test
our
instances,
and
then
we
have
two
isolated
items
in
the
package
part,
so
we
have
1604
in
abuddin
to
1804
that
is
created
prior
to
any
other.
A
The
reason
for
this
is
we
want
to
ensure
that
this
package
are
built
first
and
the
rest
of
the
process
can
be
triggered
quicker
than
actually
waiting
for
all
of
the
packages.
To
finish,
and
the
reason
for
that
is,
we
have
boon
to
1604
and
1804
in
our
environments,
and
this
is
what
we
used
to
deploy.
This
item
is
just
a
placeholder,
not
even
a
placeholder
job,
but
once
the
Ubuntu
1604
package
is
completed,
this
job
is
going
to
upload
the
package
and
then
trigger
the
deployment
on
a
specific
environment.
A
Given
that
this
is
a
patch
release,
this
deployment
will
end
up
in
our
pre
github.com
environment
automatically
and
will
be
automatically
deployed
there.
While
it's
being
deployed
there
automatically
other
package
flavors
are
going
to
be
built.
So
all
of
these
repository
all
of
these
jobs
rather
build
different
packages
for
our
system,
so
deployment
on
pre
and
package
bill
happens
at
the
same
time,
or
rather
in
parallel.
A
A
A
So
if
you
take
a
look
at
the
items
that
I'm
highlighting
here,
the
pre
environment
has
been
deployed
from
that
specific
job.
It
has
all
these
different
things
now.
This
is
the
first
time
I'm,
showing
this
instance.
Ops
instance
is
another
separate
github
instance
that
we
use
to
operate
this
whole
process.
So
so
far
we
had
github.com
where
the
development
happens,
build
repositories
on
delegates
of
the
tork,
where
the
bill
happens
and
then
ops,
repos
ops
instance,
where
we
have
repositories
that
are
used
to
operate.
A
Various
infrastructure
related
instances
that
we
have
so
this
this
pipeline
that
you
see
here
was
related
to
the
job
I
highlighted
here
in
slack,
so
announcement
channel
is
used
to
inform
informants
of
ongoing
deployments
changes
and
so
on
and
12:6
one
Enterprise
Edition
package
was
deployed
on
pre
with
deployment
to
pre.
We
have
a
couple
of
things
worth
noting
here.
This
is
basically
a
copy
of
how
our
production
and
staging
and
all
of
our
environments
are
also
deployed,
so
we
do
some
validation.
First,
we
prepare
the
environments
by
downloading
packages.
Ensuring
there
are
no
errors.
A
We
fetch
the
assets
and
execute
migrations.
Then
we
roll
out
in
at
the
same
time
to
a
subset
of
Fleet
all
of
our
packages.
So
this
means
that
the
pre
API
will
not
be
rolled
out
all
at
the
same
time,
but
with
certain
concurrency
so
say
we
have
ten
API
nodes
on
pre.
We
will
only
roll
out,
maybe
two
at
a
time,
and
that
way
we
ensure
that
we
always
have
availability
of
our
nodes
to
serve
the
traffic.
This
happens
on
across
the
nodes.
A
Once
the
deployment
is
ready
and
all
the
packages
are
built
all
of
these
packages
that
we
see,
we
are
now
back
in
our
built
instance,
where
we
build
oral
packages
when
the
packages
out
are
all
built,
they
get
uploaded
to
a
staging
package,
repository
that
that
staging
repository
is
only
there
to
hold
the
packages
until
we
are
ready
to
release
them
to
public.
This
happens.
A
Bye
once
we
are
ready,
like
I
said
once
we
are
ready
to
release,
so
we
would
take
all
these
boxes
when
we
are
ready,
when
all
of
those
pipelines
are
green.
This
item
here
is
just
there
for
release
managers
to
have
a
fallback
in
case
the
deployment
for
some
reason
didn't
happen,
but
we
should
probably
remove
that,
given
that
I
don't
think
he
said
it
has
happened
yet
that
we
had
an
issue
here
so
similar
to
that
we
also
have
similar
to
the
automated
testing.
We
also
have
a
sanity
check
here.
A
You
can
see
that
we
can
also
create
a
QA
issue
that
will
create
a
diff
between
the
two
versions
to
ensure
that
we
have
this
listed
and
all
of
the
stakeholders
in
this
process
have
a
chance
to
manually
also
verify
their
their
change
generally.
This
issue
is
informational
and
we
rely
on
automated
deployments
to
incur
it
as
to
ensure
validity
of
our
environments
when
we
are
ready
to
publish
the
packages,
meaning
blog
post
is
ready
and
we
are
ready
to
publish
our
release
to
to
self-manage
customers.
A
A
A
A
On
that
get
love
the
torque
inside
of
omnibus
github
repository,
you
can
unsee
that
now
here,
but
you
see
that
there
is
like
a
play
button
here
right
this
play
button,
or
rather
these
bills
were
all
grayed
out.
They
were
not
executed.
So
this
specific
job
will
trigger
all
of
these
manual
items
here,
play
them
basically,
and
that
would
do
a
couple
of
things
actually
only
one.
It
will
only
take
the
staging
packages
or
packages
from
the
staging
repository
and
it
will
put
them
in
a
public
repository.
A
There
are
some
other
items
here,
cleanup
jobs
and
so
on
and
so
on.
When
the
packages
are
published,
so
all
of
them
are
run
in
parallel.
We
also
have
a
similar
thing
for
our
home
charts,
so
we
publish
the
docker
images
that
we
create
and
we
publish
the
hound
chart
that
we
created
at
the
same
time,
and
we
also
do
a
couple
of
other
cleanup
items,
basically,
which
is
syncing
between
build
repositories,
canonical
repositories
and
security
repositories,
making
sure
that
our
mirroring
is
intact
and
that
all
the
tags
all
comments.
A
We
have
to
verify
steps
which
allow
us
to
go
and
make
sure
that
the
packages
are
available
for
public
and
we
create
by
clicking
this
here
we
create
a
new
version
inside
a
version
gate
level
come.
This
will
indicate
to
all
instance,
operators
who
are
looking
for
that
update
notification
to
look
out
for
a
new
version
of
github
that
we
just
published
and
we
at
the
same
time
go
and
merge
the
blog
post
that
we
created
and
that
will
indicate
to
the
public
that
the
packages
that
you
are
seeing
to
appearing
now.
A
A
So,
in
the
interest
of
time,
I
am
NOT
going
to
go
through
other
types
of
releases
that
we
have
and
I
hope.
This
was
useful
information
for
you
and
look
out
for
new
items
that
I
will
be
recording
related
to
people
that
calm
releases
and
preparation
of
a
monthly
dot,
zero
release
that
we
have.
Thank
you
so
much
for
watching
and
see
you
some
other
time.