►
From YouTube: 2020-08-04 - Security Release 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
All
right
welcome
to
another
meeting
of
the
security
releases
plus
the
auto
deploy
robert.
You
got
the
first
point
on
progress
updates.
B
Yes,
thank
you
yeah,
so
the
helm
chart
originally
was
kind
of
an
outlier
in
that
it
didn't
have
a
security
mirror,
but
it
did
have
an
auto
deploy
branch
and
we
were
making
too
many
concessions
for
that
differentiation.
So
we
just
created
a
security
mirror
for
it.
Things
like
the
boring
solution
and
that
allowed
us
to
kind
of
unblock
this
deployment
tracking,
which
is
now
working
correctly
and
the
auto
plan
security
feature
flag,
has
been
enabled
for
almost
a
week
now
I
think,
and
it
seems
to
be
working
well.
B
A
Yep,
thank
you.
So
last
week
all
the
implementation
details
were
finished,
like
the
implementation
details
needed
for
the
experiment
and
well.
Thank
you
all
for
all
your
help
there
and
the
experiment
has
been
running
so
far
since
friday.
I
have
locked
the
results
first
per
day.
A
I
put
a
comment,
a
link
for
the
observations
for
friday's
observations
in
for
mondays,
observations
and
that
take
us
to
our
discussions
where
I
have
also
the
first
point,
so
the
height
lies
so
far
of
the
experiment
is
that
we
started
on
friday
rather
than
monday,
which
gave
us
like
another
day
and
the
complete
weekend
to
observe
another
one
is
that
this
one
is
very
interesting
because
it
hasn't
reduced
the
auto
deploy
so
far
we
deployed
three
times
to
production
on
friday
and
two
times
on
monday,
there
was
a
problem
with
a
migration
yesterday,
but
that
was
completely
unrelated
to
this
experiment,
so
we
can
say
that
it
hasn't
like
reduced
the
auto
deploy
pace
there
and
also
after
merging,
like
the
security
merge
request,
the
pipeline's
on
the
auto,
deploy
and
on
master
has
been
green.
A
We
haven't
encountered
like
any
error
or
like
broken
master
or
such
and
also
like
updating
security
branches
has
been
fairly
easy.
We
haven't
encountered
any
conflict
so
far
and
well.
Master
is
updated
through
merge,
train
and
how
to
branch
is
updated.
The
regular
way
by
merging
master
into
it,
and
so
far
nine
of
22
security
fixes
have
been
merged
into
master.
Eight
out
of
those
is
already
deployed
into
production.
C
Wait
wait
before
moving
to
problems.
We
need
to
celebrate
the
fact
that
this
is
actually
working,
so
the
amount
of
you
work
that
the
two
of
you
put
in
here
is
outstanding,
so
kudos
to
both
of
you
for
driving
this.
I
think
that
needs
to
be
said
at
this
point.
Right
like
this
is
I
don't
want
to
say
that
I
was
skeptical,
but
I
was
a
bit
skeptical
that
we'll
get
this
in
in
one
go
functioning
so
outstanding
work.
I
just
want
to
say
that.
B
A
A
Nothing
is
really
blocking
us
from
moving
on
and
then
the
first
one
is
that,
when
merging
merchandise,
targeting
master
the
security
implementations
issues
were
also
automatically
closed
because
we
require
to
have
closest
and
the
number
of
security
issues,
so
we
had
to
reopen
them
and
the
other
one
is
that
robert
discovered
that
omnibus
merchant
quest
might
not
be
tracked,
because
merge
train
commits
are
only
present
on
security
and
not
on
canonical,
but
I
think
this
was
already
solved
and
jerich
also
reported
a
problem.
A
C
I,
how
are
we
addressing
the
implementation
issues
being
automatically
closed?
What
are
we
doing
about
it?.
A
Right
now,
what
we
did
is
was
to
go
there
to
the
list
of
issues
that
were
closed
and
I
put
a
message
addressing
the
author
saying
like
we
are
running
an
experiment
and
like
this
was
automatically
closed
and
I
manually
reopened
them.
We
have
like
no
implementation
details
on
that.
At
the
moment,
you
don't
need.
A
B
C
A
C
A
Yeah
I
was
thinking
like
I
had
several
ideas
at
some
point.
I
think
we
need
some
sort
of
issue
validation,
because
there
are
some
people
that
are
not
checking
all
the
all
the
boxes
and
there
are
some
people
that
are
also
not
filling
out
all
that
implementation.
A
A
Okay,
yeah
brother.
B
B
B
A
Exactly
yeah,
okay,
so
now
to
the.
I
think
this
will
be
one
of
the
interesting
points.
I
really
can't
see
us
using
this
process
like
in
the
future,
so
merging,
merge,
request
targeting
master
as
soon
as
they
are
ready,
picking
them
into
the
current
auto,
deploy
and
deploying
them,
and
then
the
backboards
will
be
merged
during
the
security
release
and
security
master
will
be
updated
with
canonical
master.
C
Amy
feel
free
to
speak
up
before
me,
because
obviously
I
have
too
many
ideas
about
this,
but
my
first
question
that
is
not
strictly
related
about
this
process.
It
is
what
are
we
going
to
do
tomorrow
when
we
create
the
patch?
C
A
Okay,
so
to
bring
the
fixes
from
security
master
into
canonical
master,
we
are
going
to
use
the
sync
task,
the
one
that
we
have
been
using
so
far,
and
we
cannot
process
well.
The
the
tooling
is
implemented
in
a
way
that,
with
the
flag
enabled
we
are
only
going
to
process
issues
that
have
either
the
four
merge
requests
open
or
one
merge
request,
targeting
master
merge
and
the
back
ports
are
also
merged.
A
So
what
I
am
trying
to
say
is
that
the
point
that
you
made
is
already
implemented
in
our
tooling.
It
is
like
just
under
the
feature
flag
that
we
have
enabled
so
far.
A
You
said
that
what
will
happen
if
we
merge
a
merchant
quest
already
master,
but
the
blackboards
are
not
ready.
So
that
cannot
happen
because
to
merge
the
merchant
question
master.
We
actually
ensure
that
the
blackboards
are
ready,
like
approve
and
with
pipelines,
read,
etc,
etc.
A
C
I
see
what
you
mean,
so
the
situation
can
happen
where
at
midnight
tonight,
at
the
ex
like
when
the
experiment
is
running
out,
we
merge
something
and
then
tomorrow
we
are
not
ready
to
release
because
backwards
are
not
ready
right.
The
tooling
is
not
allowing
us
to
do
that.
C
C
C
A
Yeah,
I
don't
think
nothing
is
preventing
us
that
what
I
would
like
to
perhaps
implement
before
that
is
to
also
enable
merge
request
pipelines
for
security.
Merge
requests
because
we
have
in
those
we
don't
have
those
enabled
on
security
projects
so
for
canonical
projects.
What
we
do
as
maintainers
is
that,
once
we
approve
all
the
all
the
merch
requests
we
hit
merge
when
pipeline
succeeds,
and
that
runs
the
test
suite
on
the
latest
master
and
then,
if
all
that
is
green,
then
the
merchant
quest
is
merged.
A
In
this
case,
we
don't
do
that
for
security,
merge
requests,
we
merge
immediately.
So
technically
a
security
merge
request
can
break
master
because
it
is
not
updated.
So
I
think
the
first
step
to
do
that
is
to
enable
that
and
then
just
have
the
bot
to
trigger
the
pipeline
and
to
set
merch
when
pipeline
succeeds.
C
A
A
I'm
sorry
I'm
sorry,
I
just
received
a
call
and
that
block
my
own.
B
C
C
Immediately,
all
right,
I
don't
want
to.
B
I
also
don't
have
any
like
concrete
examples,
but
I'm
worried
about
potential
like
timing
issues
where
somehow,
like
we
run
this
automated
merge
and
that
merges
something
and
then
either
we
had
just
run
an
auto
deploy
creation
or
we
are
just
about
to
and
something
gets
missed
or
something
like
I
haven't
thought
about
it
enough
to
actually
think
of
actual
problems,
though
I'm
a
little
worried
about
that
and
I'm
more
comfortable
currently
having
it
just
run
like
it's
a
chat,
ops
command.
It's
not
that
big
a
deal
right.
C
Well,
this
is
the
right
project
for
you,
then
okay,
so
the
other
thing
that
I
wanted
to
ask,
which
was
really
not
important
last
week,
but
I'm
thinking
about
it
right
now
that
we
actually
ran
the
experiment
is
master
insecurity.
C
Does
that
end
like
do
anything
to
our
history
at
all?
Actually
what
am
I
saying?
We
had
a
single
code
based
merge.
Our
history
is
a
mess
anyway,
so
that
doesn't
matter,
I
guess
like
what
the
thing
I
was
wondering
is
whether
this
dirt
is
the
history
in
any
way.
By
having
these
weird
merge
commits
that,
don't
say
anything
basically,
it
just
says
merged
master
into
master.
B
B
C
Could
you
create
an
issue
for
that
roberts
and
maybe
talk
with
remy's
team
and
maybe
like
expand
it
a
bit?
I
mean.
Obviously,
everyone
is
going
to
have
an
opinion
about,
should
we
rebase
or
should
we
or
should
we
fast
forward
or
not
fast
forward
and
blah
blah
blah?
All
of
that,
but
just
so
we
can
double
check
before
we
increase
any
sort
of
frequency
there.
A
C
B
B
Into
my
question,
which
is
how
often
do
we
want
to
run
this
merge
string?
Oh
you
know.
My
first
question
is:
do
we
want
to
enable
it
permanently
or
just
kind
of
trigger
it
once
the
master
branch
has
been
diverged
it,
but
it
sounds
like
if
we're
regularly
merging
security.
Mrs
as
soon
as
it's
ready,
then
we
just
have
to
leave.
It
enabled
all
the
time.
A
B
A
I
mean
if
we
recall
the
investigation
we
did
initially
about
having
the
merch
request.
The
security
issues
actually
are
ready
like
on
the
last
week
of
the
month.
I
don't
think
it
is
in
our
best
interesting
interest
to
have
merch
train
enable
like
forever,
because
it
basically
won't
do
anything
so
perhaps.
B
A
Can
yeah
we
can
use
the
mirror
output
to
actually
trigger
the
merge
train
and
have
kind
of
a
pipeline
schedule
to
do
that.
That
would
be
great.
C
Yeah,
if
that's
possible,
that
would
be
that
would
be
actually
pretty
nice,
even
though
it
is
a
bit
of
over
engineering.
In
my
view,
honestly,
but
for
the
reasons
I
just
asked
about
master
and
how
often
do
we
have
merch
commits
and
all
of
that
it
would
be
nice
to
minimize
that.
C
Because
keep
in
mind
well,
no,
no,
it
doesn't
matter.
No
sorry,
I
was
thinking
about
gitlab
false,
but
that
doesn't
matter.
A
B
Question
was
yeah.
How
often
do
we
want
to
run
the
merge
train
when
it
is
enabled
do
we
want
to
do
it
on
every
commit
or
hourly,
even
more
often
than
hourly?
My
problem
with
on
every
commit
is
that
it
currently
takes
around
four
minutes
to
run
the
merge
strain
because
it's
downloading
cash,
the
actual
operation,
is
pretty
quick,
but
it's
downloading
cached
a
cache
of
two
full
copies
of
the
gitlab
repository
straight
two
gigs
or
so,
and
then
running
the
operation,
pushing
and
then
uploading
the
cache.
D
B
A
Can
we
just
relate
this
to
your
previous
point,
robert
about
triggering
based
on
the
mirror
divergence
status,
and
then
we
will
just
trigger
it
once
if
the
mirrors
are
diverged.
B
A
C
C
D
So,
just
to
summarize
we're
going
to
are
we
going
to
leave
the
auto
deploy
branch
over
on
staging
now?
What's
the
what's
the
kind
of
status
as
we
exit
out
of
tomorrow.
B
A
C
C
Created
exactly
okay,
so
by
sheer
fact
that
it
is
first
time
auto,
picked
and
then
from
the
next
time
it's
in
the
in
the
auto
deploy
branch.
There
is
no
edge
case
there.
That
can
happen
that
we
miss
something.
C
A
Okay,
so
we
have
four
minutes
just
trying
to
summarize
what
are
the
next
action
items
so
robert?
I
think
you
are
going
to
investigate
if
the
march
train
is
going
to
dirt
the
history
on
canonical-
and
also
I
I
mean
it
is
important,
but
it
doesn't
have
like
a
very
high
priority
from
my
point
of
view
and
also
like
investigable,
and
on
my
side,
I
am
going
to
well
grab
up
the
experiment
and
the
security
release
and
also
investigate
what
is
needed
to
actually
trigger
like
their
own.
C
B
A
But
why
wouldn't
be
ready
to
be
included
in
the
next
security
release?
I
mean
if
all
the
backboards
are
ready
and
approved
and
master
was
ready
and
approved
by
maintainers
and
upset.
I.
C
So
think
about
like,
if
we
are
not
talking
about
the
window
here,
if
we
are
talking
about
this,
is
on
tomorrow,
we
are
releasing
based
on
the
things
that
are
merged
into
master,
but
while
you're
preparing
the
back
ports,
something
can
already
be
merged
into
master
already.
And
then,
when
you
do
the
publish
task,
it
can
be
anything
between
an
hour
and
five
hours.
Maybe
two
days,
even
probably
not
you
do
a
sink
of
master
and
then
you
expose
a
fix.
That
is
right.
Timing
is
there
that
you
hear.
C
But
I
wouldn't
honestly
at
this
point-
I
think
let's
address
these
things
and
take
a
breather
as
well
for
a
bit
like
once.
We
address
some
of
these
edge
cases
and
think
about
automation
and
so
on,
and
then
only
think
about
whether
we
can
expand
this,
because
I
want
to
give
both
of
you
a
bit
of
time
to
just
right
to
take
care
of
yourself
a
bit.
A
A
Okay,
well,
it
is
time,
thank
you
so
much
for
joining,
and
I
will
see
you
next
time
and
around
bye.