►
From YouTube: Delivery Fast Boot: Day 2 summary
Description
Delivery team fast boot Day 2, task summary.
The issues listing the work done are contained in epic https://gitlab.com/groups/gitlab-org/release/-/epics/17
B
C
You
ready
yeah,
so
I
was
working
on
the
auto
picker,
so
Rob
did
the
majority
of
the
work,
but
we've
at
least
I
figure
out
what
to
do
with
making
sure
mentioning
the
right
people.
So
we
added
that
at
the
very
end
of
the
day.
So
that's
done.
We
diverged
from
using
the
release
tools
to
perform
the
CDE
merge
it.
We
just.
C
This
plan
to
create
a
trigger
to
our
existing
merge
train
tools,
so
you're
created
a
merge
request
to
update
where's
trains
that
accepts
additional
variables
that
allow
us
to
configure
the
project
as
well
as
the
branches
that
we
want
to
do.
The
merge
from
and
we've
kind
of,
merge
request
in
for
the
release
tools
to
do
that
trigger
the
one
line
item
here,
the
ticket
lab
repos
and
push
to
dev.
We
can't
exactly
do
that
because
we're
relying
on
the
merge
trained
to
perform
that
actions
correct.
A
A
A
A
A
A
B
We
decided
we
would
keep
track
of
this
in
a
flat
JSON
file
in
the
deployer,
and
the
idea
is
that
we
trigger
this
at
the
end
of
the
deploy,
pipelining
story
version
and
then
using
that
database
we
can
generate
the
QA
issues.
Basically,
a
previous
version.
We
store
it
in
the
current
one
and
generating
in
QA
issues
will
still
be
done
using
the
police
tools
which
we
were
just
triggered.
My
chain
awesome.
D
D
A
D
Still
a
little
bit
on
the
fence
on
the
naming
that
it
doesn't
have
anything
on
it
deploy
inside
of
it
right
now,
it's
just
11
10,
which
is
the
target
release,
and
then
you
know
each
on
the
bus.
So
it's
fairly
generic
on
one
hand
it's
harder
to
identify
quickly
as
an
auto
deploy
tag
the
other
hand,
it
looks
nice
I,
think
we'll
be
nicer,
but
we
when
that
is
reported
as
the
version
and
had
like
auto
deploy
in
the
version
strength
that
you
get
from
staging.
For
example,
it.