►
From YouTube: Delivery Fast Boot: Yorick task Day 1 summary
Description
Delivery team fast boot Day 1, Yorick recaps the challenges of the task for automatically generating list of changes after deploying to environments.
The issues listing the work done are contained in epic
https://gitlab.com/groups/gitlab-org/release/-/epics/17
B
No,
I
I
looked
into
the
automatic
generation
of
qba
issues,
specifically
getting
the
current
version
before
deploy.
Do
the
deploy,
get
the
version
act
and
then
generate
the
qa
issue
still
working
on
that
trying
to
figure
out
how
to
get
this
data
from
prometheus
using
the
chef
api.
So
you
need
the
internal
ip.
A
B
B
B
No,
I
in
a
long
term
it
will
be
nice
when
we
do
a
deploy.
We,
prior
to
the
package,
upgrade
we
generate
sort
of
a
previous
version
file
somewhere
on
the
host,
with
the
version
that
we
sort
of
upgraded
from
and
a
file
with,
the
version
we're
upgrading
to,
and
then
we
can
just
pull
it
from
some
arbitrary
hosts
and
we're
done.
Although
then
you
still
need
ssh,
it
might
be
even
nicer
to
take
the
step
forward.
Just
have
a
kill
up
api
that
spits
out
an
information.
B
Particularly
sensitive
and
you
could
use
an
administrator
api
to
good
for
a
bit
overkill.
The
problem
then
gitlab
has
to
be
aware
of.
Like
okay,
you
know:
where
do
we
keep
the
version?
I
think
we
need
a
database
table
for
that
or
something
right
so
right.
But
then
you
need
an
api
to
store
that
we
need
to
hook
that
up.
Somehow
we
need
to
get
it
and
that
will
be
nicer,
but
then
we're
probably
three
months
further
ahead.