►
From YouTube: 2020-07-21 - Security Releases as part of auto-deploy
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
Okay,
well,
thank
you,
everyone
for
joining
to
another
security
releases
as
part
of
how
to
deploy
let's
quickly
go
through
the
progress
updates.
Robert.
You
have
the
first
point.
B
Yeah,
I
just
wanted
to
celebrate
a
quick
win.
We
already
got
some
positive
feedback
from
apsec
about
myers,
validating
security,
merge
quests
before
their
merged
work.
So
that's
awesome
to
see.
B
Last
week
we
talked
about
the
possibility
of
automating
the
back
ports
if
the
cherry
picks
would
apply
cleanly
from
the
master
branch.
So
we
ran
some
data
on
that
and
after
correcting
our
and
our
assumptions
about
what
constituted
being
exactly
the
same,
we
actually
found
out
that
55
percent
of
the
merchandise
targeting
stable
branches
were
identical
to
their
master
counterparts
and
could
have
been
cherry-picked
cleanly.
B
So
I
think
that's
a
potential
of
a
lot
of
savings
for
developer
toil
so
pursuing
that
I
started
implementing
dry,
run
cherry
picks
and
also
rewords,
because
that
kind
of
comes
for
free
and
giddily,
and
that's
currently
in
review.
There's
some
push
back
on
the
goodly
side,
because
that
kind
of
always
happens
with
my
github
emergency
classes.
That's
something
I'm
not
accounting
for,
but
that's
in
progress,
and
I
think
that's
promising
myra
he's.
B
B
So
internally,
when
you
cherry
pick
something
it
returns
the
sha
of
the
new
commit,
but
since
we're
not
actually
committing
something,
I
needed
something
to
return,
so
I
decided
to
return
the
shot
of
the
existing
commit
it's
like
already
at
the
top
of
the
head,
but
there
was
some
pushback
on
that.
So
that's
going
back
and
forth
myra.
How
was
your
experiment.
A
B
Yeah,
so
it's
kind
of
a
never
ending
stream
of
problems
with
autodeploy
is
potentially
only
existing
on
the
security
repository.
The
latest
one
is
that
it
breaks
deployment
tracking
because
we
track
when
we
deploy
something.
We
tell
the
canonical
ehee
repository
that
we
deployed
it
and
then
it
gathers
gathers
up
all
the
emerging
quests
in
that
chain
set.
I
guess,
but
since
the
branch
won't
exist
on
canonical
it
doesn't
know
anything
about
it
and
we
can't
track
it
so
yeah.
I
think
there's
two
options
there.
B
B
So
I
think
york
suggested
potentially,
if
we're
not
doing
a
security
release,
then
we
mirror
the
repo
the
deployment
data,
I'm
not
sure
how
feasible
that
is
or
sorry.
My
interrupt.
A
I
mean
we
can
use
that
in
the
experiment.
Right
like
we
can
see
what
are
the
disadvantages
of
having
something
cherry,
picking,
security,
auto
deploy
and
not
on
canonical,
and
then
just
gather
all
this
that
information
and
see
what
we
are
going
to
do,
because
we
really
need
to
show
the
deployment
information
on
canonical
like
this
is
something
that
we
need,
and
I
don't
know
the
implementation
details
of
of
mirroring
the
deployment
data
to
security,
and
that
sounds
like
it
might
take
a
while.
B
Yeah,
so
I
think
going
forward
I'll,
probably
just
have
to
abandon
my
auto
employee
on
security,
feature
flag
and
revert
all
that
stuff,
because
I
don't
think
it's
going
to
be
feasible.
So
I
think
the
good
news
is
that,
because
we're
no
longer
updating
italy
regularly
on
the
auto
deploy
branch
and
assuming
we
don't
cherry
pick
like
a
p1
p2
fix,
then
the
auto
deploy
branch
doesn't
really
get
updated.
That
often
day
to
day
it's
just
when
we
create
it
from
the
latest
master.
C
A
I
mean
you
mentioned
robert
that
we
need
to
abandon
the
idea
of
having
auto
deploy
on
security,
but
I'm
not
sure
if
that
is
one
hundred
percent.
True
I
mean
I
think.
B
A
B
B
B
Yeah
so
when
we
cherry
pick
a
security
fix
into
the
auto,
the
current
auto
play
brands
on
security,
and
then
we
deploy
that
and
that
goes
through,
and
then
we
that
comes
back
and
tells
the
deployment
tracker
to
track
it.
In
the
canonical
repository
on
the
auto
deploy
branch,
that
branch
will
exist
in
canonical,
so
it
might
work
a
little
bit,
but
I
don't
know
what
it
will
do
with
the
merge
requests
that
only
exist
in
security.
A
C
Right
so
I
guess
and
enlighten
me
here:
I'm
probably
missing
something,
but
that
means
we
can
also
edit
it.
So
we
can
also
easily
say,
track
everything
and
rescue
whatever
gets
thrown.
As
I
was
not
able
to
find
this,
I
don't
know
how
to
compute
and
say
I'm
going
to
attempt
another
time
now
with
this
bunch
of
things
in
security
and
see
whether
I
can
find
it
and
if
I
don't
find
that
second
time
do
something
right
like
inform
us
or
ignore
or
whatever
right.
B
A
C
C
Very,
but
does
that
mean
gold
mirror
will
have
diverged
branches
on
canonical
and
security.
The
words
auto
deploy
branches.
B
A
C
No,
that's
true.
One
thing
that
I
think
we
need
to
add
to
some
safeguards
is:
how
do
we
get
informed
when
a
cherry
pick
into
one
of
the
auto
deploy
branches
fails
because
of
divergence?
B
C
C
I
mean
that's
also
a
concern,
but
a
bigger
concern
like
that
part
is
fine,
because
we
are
going.
Oh,
no,
it's
not
fine.
If
we
use
merge
train,
it
doesn't
matter
right,
like
it's.
Gonna
still
be
diverged
between
the
two
branches,
so
we
won't
be
able
to
mirror
but
we'll
be
able
to
merge
train
all
the
time.
B
C
Yeah,
which
is
not
gonna,
happen
right,
but
what
I'm
saying
is:
let's
take
a
sample
of
five
days
in
a
work
week,
right
something
was
merged
into
security
master
and
which
I
repeat,
that
into
monday's
auto,
deploy.
A
Outside
yeah,
the
auto
deploy
branch
will
be
created
from
security
master,
not
from
canonical
master,
but.
A
Yeah
we
haven't
decided
on
a
particular
time
frame,
but
we
were
talking
about
on
the
issue
about
having
it
basically
on
every
commit.
It
seems
there
was
no
negative
consequence
of
running
the
merch
train
like
on
every
commit
once
like
it
is
merging
to
master
and
then
reflect
it
into
the
other
monster.
B
C
Now:
okay,
let's
that's
not
the
topic
I'm
trying
to
cover
here
so
I'll.
Put
that
for
for
a
bit
later.
The
point
I'm
trying
to
make
is
that
if
we
get
those
changes
from
canonical
master
into
down
security
master,
how
do
we
fail
when
there
is
a
divergence,
because
something
on
canonical
master,
updated
the
code
or
removed
something
that
was
in
security,
master.
A
I
think
what
happens
now
like
with
the
gitlab
false.
I
guess
we
don't
have
that
problem
now
with
willa
faulk,
because
it's
not
modified
right,
but.
C
C
A
Yeah
yeah
yeah,
but
sometimes
when
we
merge
something
like
taking
the
example
between
gitlab
and
gitlab.
Sometimes
we
modify
something
in
gitlab
that
makes
gitlab
false
fail
because
we
don't
roll,
we
don't
run
gitlab
false
tests
on
gitlab
and
then
once
it
is
merged
by
merge
trading
to
get
laptops.
These
things
fail
and
an
alert
is
sent
into
master,
broken
or
rocket
master
channel.
I
don't
remember
the
name,
so
I
guess
we
can
do
some
sort
of
the
same.
A
We
can
just
trigger
an
alert
on
the
delivery
channel
or
we
can
create
another
channel
and
then
just
trigger
something
there,
and
then
we
will
need
to
take
manual
action
like
whether
the
release
manager
of
one
of
us.
B
C
C
Yeah,
I'm
the
reason
why
I'm
concerned
about
that
is:
if
we
have
a
gap
in
qa,
which
we
all
know
that
we
probably
do,
there
is
a
chance
that
things
are
gonna
be
broken
really
badly.
C
The
application
is
still
gonna
start
somehow,
but
we're
gonna
have
like
a
completely
broken
feature
that
is
not
covered
in
qa
tests,
but
it's
not
smoke
so
yeah,
maybe
I'm
being
a
bit
too
pessimistic
here.
D
I
think
I
think
you're
right,
though,
that
we
need
to
make
sure
it's
really
visible
when
it
happens.
What
I'm
concerned
about
is
it's
most
likely
to
happen
in
the
european
morning,
which
means
that
robert
murray,
you
won't
be
online,
so
I
think
we
need
to
make
sure
we
know
what
it's
going
to
look
like
and
what
we
do
when
it
happens.
C
C
Yeah,
like
a
round
book
of
some
sorts
or
like
who
do
you
reach
out,
or
what
do
you
do?
I
mean.
Theoretically,
there
are
many
options,
but
it's
just
like
how
do
you
recover
from
that
breakage
if
it
happens
in
a
european
morning,
but
then,
like
the
owners
of
the
code,
were
pacific
zone
right,
so
we
have
a
big
big
gap.
C
I
guess
everyone,
every
one
of
folks
that
we
can
involve
are
developers.
They
should
be
able
to
figure
it
out,
but
it's
a
it's
an
edge
case
that
has
serious
consequences.
That's
why
I'm
worried
about
that's?
Why
I'm
being
a
bit
cautious
about
it.
A
Okay,
so,
regarding
the
latest
issue
with
auto
deployment
security,
we
need
to
see
if
we
can
mirror
yeah.
We
need
to
see
if
we
can
mirror
the
deployment
information
into
security.
Somehow
I
will
ask
jorik
what
are
the
possible
options
here
and
try
to
understand
how
it
is
currently
implemented
and
then
so
moving
on
regarding
the
experimental
that
we
want
to
run,
I
outlined
some
some
implementation
steps
that
are
on
the
issue
and
well,
given
that
nothing,
it
is
actually
implemented
so
far.
A
It
shouldn't
be
that
problematic,
but
we
need
kind
of
time
to
do
it.
I
propose
to
cut
or
reduce
the
experiment,
the
experiment
days
and
that
will
start
by
moving
the
security
release,
perhaps
one
day
to
july
30..
It
is
currently
scheduled
for
july
29,
but
I
think
we
can
move
it
just
one
day.
We
might
need
confirmation
from
apsec
for
this
and
then
just
run
the
experiment
only
on
july,
27
and
july
28th.
C
I
would,
I
would
suggest,
being
a
bit
more
cautious
here.
Mara,
cautious
is
a
wrong
word
here,
not
necessarily
cautious,
but
instead
of
saying
38
just
saying
monday.
The
3rd
of
august
is
the
target,
because
38
is
already
thursday,
and
you
know
what
happens
if
we
have
a
delay
we
can't
deploy.
We
cannot
release
on
friday,
friday
or
we
don't
want
to
release
on
friday,
so
wanna
play
it
safe
and
just
inform
abstract
that
this
is
gonna
happen
on
the
third
of
august.
A
Yes,
the
third
of
august
is
it's
monday
yeah.
It
is
monday
us,
so
that
will
mean
that
we
will
need
to
start
security
release
on
friday
and
do
the
mergers
and
all
the
things
on
friday.
So
we
can
actually
publish
the
packages
on
monday,
and
that
would
also
mean
that
the
branches
will
be
out
of
sync
between
all
the
weekend
between
the
weekend.
C
Tuesday,
I
mean,
I
think
you
have
all
the
power
to
make
a
decision
on
when
exactly
are
you
targeting?
I
think
this
is
important
enough
in
a
big
enough
change
to
argue
that
we
want
a
target
for
to
focus
and,
honestly,
I
would
say
it
rather
than
ask
right
like
we're
targeting
4th
of
august.
We
need
more
time.
A
Ok,
ok,
just
I'm
trying
to
looking
ahead
there
this
morning.
Also
someone
from
broner
sent
a
message
on
release
a
release,
saying
like
hey.
We
are
going
to
execute
a
security
release
on
runner
at
the
same
time
of
the
gitlab
security
release.
I
guess
those
days
are
also
going
to
be
moved
or
is
that
something
that
we
shouldn't
be
concerned
about.
C
It's
really
tricky
because
runner
is
a
satellite
repository
like
a
satellite
repository,
and
we
already
know
what
kind
of
problems
we
have
with
satellite
repositories,
it's
kind
of
hard
to
get
a
release
streamlined
there
anyway.
That
would
be
my
suggest,
suggestion
myra,
because
I'm
afraid,
like
we
had
a
bit
of
a
bumpy
couple
of
days,
if
you
put
too
much
pressure
on
well,
both
of
you
actually
to
achieve
all
of
this
and
then
also
give
yourself
only
two
days
and
then
also
one
of
the
deadlines
is
on
thursday.
A
Yeah,
that
sounds
totally
reasonable
marin.
Thank
you
for
bringing
it
up.
So
what
do
we
say?
We
move
it
basically
like
for
a
week.
We
have
the
deadline
for
august
five
fifth,
and
then
we
run
the
experiment
on
august
third
and
four,
which
is
basically
from
monday
to
wednesday,
and
then
we
have
the
whole
next
week
to
have
all
the
implementation
details.
C
C
A
B
B
The
auto
deploy
branch
gets
created
from
security
master
where,
like
it
has
to
be
created
on
security.
So
then,
that
branch
doesn't
exist
on
canonical
because
it
has
security
fixes
in
it
and
we
can't
track
it.
We
have
to
create,
like
a
dummy,
auto
deploy
branch
on
canonical
from
canonical
master
like
what
I
don't
that.
C
C
Well,
no!
Actually,
there
is
no
point
in
discussing
this
until
we
get
the
understanding
of
how
much
change,
how
many
changes
or
how
flexible
it
is
the
tracking
deployment
tracking
code,
because
if
it's,
if
I
found
all
of
this
in
canonical,
then
do
this.
If
I
didn't
do
this
in
security
and
track
in
both
places,
we
don't
have
to
talk
about
this.
Then
right.
C
B
B
A
Yeah,
but
that
that's
adds
confusion
yeah.
It
will
be
admiring.
We
all
know
that,
but
the
confusion
will
be
like
on
us
right,
because
no
one
else
cares
about
the
content
of
the
apple
deploy
branch,
and
that
is
something
we
discuss
like
on
one
of
our
first
meetings,
so.
C
C
We
still
continue
creating
branches
as
normal
right,
but
we
still
create
economical,
do
the
same
process
we
currently
have,
but
when
the
window
is
enabled,
the
additional
thing
is
once
the
branch
is
created
in
canonical,
we
trigger
merge
from
mastering
to
autodeploy
security
master
into
autodeploy
on
security.
C
C
Security
master
into
the
freshly
mirrored
autodeploy
branch.
So
let
me
repeat
again:
we
do
everything
as
we
are
doing
right
now,
so
canonical
master.
We
create
canonical
auto,
deploy
branch
right.
Let's
assume
the
security
master
already
has
some
security
fixes
merged
earlier
mirroring
will
mirror
from
canonical
auto
deploy
to
security
or
to
deploy
the
security.
Auto
deploy
will
contain
no
no
security
fixes
from
last
day,
but
at
that
moment
our
creation
of
auto
deploy
branch.
C
We
also
merge
security
master
into
auto,
deploy
master
into
auto,
deploy
security
on
to
deploy,
which
brings
it
up
to
speed
to
what
we
had
in
master
in
security.
B
C
Know
and
after
the
window
ends
after
the
window
ends,
we
sync
every
master.
We
sing
completely,
so
we
are
okay
with
diverged
master
in
between
canonical
and
security
for
the
period
of
the
security
window,
and
we
are
fine
with
that,
because
we
still
create
auto
deploy
branch
from
the
canonical
sorry,
I
need
to
leave.
A
Yeah
I
was
trying
to
understand
what
marin
was
saying
and
I
think
my
brain
just
exploded,
but
okay,
so
I
don't
want
to
take
more
minutes
into
this
meeting.
I
will
try
to
put
all
the
problems
that
we
discussed
in
this
meeting
on
the
issue,
so
we
can
discuss
it.
I
think-
and
I
think.
A
Yeah
yeah,
that
would
be
perfect
so
just
very
quickly.
We
do.
We
have
like
actions
like
next
items
to
work
on.
I
will.
A
Okay,
so
from
my
site,
I
will
work
on
trying
to
outline
all
the
implementation
steps
that
we
need
for
the
experiment.
I
will
make
the
announcement
that
security
release
is
going
to
be
moved
by
a
week
and
robert
on
your
side.
If
you
could
work
with
joric
to
try
to
see
and
to
have
very
clear
how
the
deployment
data
it
is
well,
it
is
working
out
and
if
we
can
make
it
work
for
the
experiment,
that
would
be
great.