►
From YouTube: 2023-04-04 Delivery:Orchestration demo - EMEA/AMER
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
B
I'm
gonna
go
ahead
and
go
over
some
changes.
I'm
making
to
the
merge
train,
so
I
will
share
my
screen
and
see
if
I
remember
what
I
was
doing
here.
So
much
chain
is
interesting
because
it's
just
essentially
one
big
bash
script
and
let
me
go
ahead
and
actually
bring
the
code
over.
So
the
the
issue
that
I'm
working
on
is
what
we'd
like
to
do
is
when
a
merge
chain
fails
to
merge
from
canonical
security,
which
is
somewhat
common.
B
The
current
process
allows
that
these
failures
happen
and
then
it's
up
to
a
release
manager
to
kind
of
like
see
that
they
failed
in
slack
or
somewhere
and
then
follow
the
process
to
sync
them
up
manually,
which
just
consists
of
pulling
the
different
repos
emerging
them,
fixing
any
conflicts
and
then
creating
an
MR.
So
this
issue
is
meant
to
automatically
create
the
merge
request.
So
that
way
it
saves
the
release
manager.
B
So
here's
an
example
of
a
job
that
failed,
and
so
we
can
see
that
it's
it
just
fails
it
logs
out
the
various
conflicts
that
occurred.
That's
about
it
so
there's
not
much
else.
Information
happening
and
I
believe
it
posed
to
slack
when
it
fails.
B
So
in
terms
of
what
we
actually
need
to
do.
Merge
chain,
as
I
mentioned,
is
one
big
bash
script
and
the
specific
merging
process
for
security
happens.
When
we
run
this
merge
function
and
there's
a
couple
different
rules
in
here
and
what
ends
up
happening
is
we
merge
and
if
it's
merging
into
security
we
will,
let
me
make
sure
I'm
in
the
right
spot.
Here
it's
been
a
few
days
since
I
looked
at
this.
Actually,
let's
see
yeah.
B
If
secure,
if
we're
using
security,
then
we
don't
use
any
of
these
recursive
options,
so
the
recursive
options
are
essentially
saying:
let's
fix
the
complex
automatically
as
we
merge
using
these
options.
So
when
we
merge
from
security
or
into
security,
we
don't
want
to
do
that.
We
want
to
actually
see
the
conflicts
happen,
and
so
the
current
behavior
is
that
all
we
do
is
we
end
up.
Logging
out
the
status
and
the
diff,
and
this
diff
I
learned
recently
from
Reuben
that
this
actually
as
a
non-zero
exit
status.
B
B
What
was
some
of
these
comments?
To
start.
B
B
Yeah,
so
what
we
end
up
doing
here
is
we
try
to
do
the
merge
and
if
the
merge
is
unsuccessful,
so
if
it's
successful,
then
we
we
just
you,
know
push
that
change,
but
if
it's
unsuccessful,
then
we
need
to
create
the
merge
request.
So
we
do
that
by
adding
all
the
changes,
because
we're
essentially
in
a
conflicting
state
where
we
have
unstaged
changes
that
that
have
all
of
the
different
conflicts
listed.
B
B
You
can't
change
branches
in
the
middle
of
this
conflict,
so
we
commit
on
this
current
Branch
and
then
we
create
a
new
branch
which
is
going
to
be
our
merge
conflict
branch,
which
is
just
sync,
the
security
with
canonical,
and
we
check
out
that
branch
and
push
the
merge
request
and
so
I'm
trying
to
remember.
If
there's
something
else
specific
here
but
pushing
that
conflict.
Merge
request
also
has
a
few
steps
as
well.
So
if
we
look
at
what
happens
there,.
B
We
take
the
branch
name
and
we
have
you
know
this
kind
of
timeout
attempt
to
push
it,
which
is
highly
so
far.
It's
highly
copied
from
the
other
push
functionality
for
the
when
there
is
no
conflicts.
The
main
difference
here
is
we're
creating
a
merge
request,
so
we
pass
in
the
options
to
create
the
merge
request,
ping.
B
The
release,
managers
and
also
I've
got
the
options
set
here
to
remove
the
branch
once
it's
complete
and
so
I
was
able
to
test
this
out
locally
by
just
creating,
let's
see
if
I
can
find
it
here.
B
I
created
a
project
on
just
a
group
that
I
have
set
up
for
testing
purposes,
and
all
it
has
is
this
readme
and
I
created
a
commit
on
the
readme
that
just
changes
this
first
getting
started
line
and
then
on
a
separate
Group,
which
kind
of
is
the
you
know
the
security
I
guess
version.
So
it's
a
private
group
I
did
the
same
thing
and
created
a
different
commit
that
updates
that
same
line.
So
we
are
forcing
the
conflicts
to
happen
when
we
try
to
merge
and
I
ran
the
script
locally
against
it.
B
So
what
we
can
do
is
we
just
set
up
the
project
directory
for
my
local
setup,
but
where
I
want
these
to
get
pulled
down
to
so
this
is
kind
of
like
inside
of
the
actual
CI
job
it
clones
these
projects
and
then
tries
to
merge
them
and
then
I
set
the
source
project.
B
So,
if
I
open
up
that
merge
request,
this
is
kind
of
what
it
would
end
up.
Looking
like,
of
course,
pings
me
because
I
didn't
want
to
Ping
all
the
release
managers
in
my
test
and
then
in
the
changes
we
have
our
conflict
merge,
and
so
this
way
the
merger
or
whatever
release
manager
is
available
at
the
time,
can
then
go
ahead
and
check
this
out
fix
up
any
conflicts,
push
the
changes
and
then
keep
it
moving
along.
So
it
removes
those
few
steps
for
them,
and
this
is
currently
in
review.
B
So
I
have
a
few
comments
that
I
haven't
really
looked
at
yet,
but
otherwise,
if
anyone
has
any
comments
on
the
overall
sort
of
like
outcome-
or
you
know,
if
there's
any
other
sort
of
ideas
on
how
it
could
be
improved
or
look
a
little
different.
C
C
C
D
C
B
D
There's
also
another
thing
that
I
wrote
in
the
review,
which
is
this
thing
run
on
a
pipeline
on
a
schedule,
so
the
second
run
will
just
skip
breaking
that's
the
same
thing,
because
you
are
using
the
same
Branch
name
every
time
and
by
the
time
it
runs
again.
No
one
will
unheard,
will
have
these
things
fixed
and
merged,
because
even
just
finding
the
authors
being
no
pinging
them
say,
could
you
fix
this
and
then
having
the
pipeline
run?
D
It
takes
more
than
the
time
it
takes
for
for
the
next
job
to
restart
so
checking
if
the
branch
exists
or
something
like
this
may
be
an
option
to
begin
with,
and
then
there's
other
thing,
which
is
that
all
retry
thing
is
not
necessary
here
because
of
the
problem
that
is
trying
to
handle
is
on
the
Foss
merge.
The
first
merge
is
completely
different
because
it
runs
on
pipelines
from
a
GitHub
project.
So
when
you
commit
on
master
or
on
stable
branches,
you
are
triggering
a
merge.
D
A
false,
merge
train
for
that
specific
Branch.
So
in
that
case
you
are
actually
competing.
So
if
you
merge
three
things
on
the
same
stable
Branch
this,
this
will
trigger
three
first
merge
train
and
they
will
compete
for
master
access,
and
this
is
why
it
has
that
problem
of
it
may
not
be
able
to
push,
but
you
are
creating
a
merge
request.
So,
regardless
of
if
the
target
moves,
the
first
run
will
work.
D
If
it
doesn't
work
in
the
first,
it
will
never
work
so
the
the
whole
function
you
were
doing
can
you
can
basically
remove
everything
and
just
put
the
push
command,
because
it's
the
only
line
that
you
only
that
you
ever
need,
but
the
I
think
the
cheapest
part
will
be
detecting
if
this
is
already
running
and
things
like
that
right
and
yeah.
This
is
the
thing
that
I
want
to
mention.
On
top
of
that,
we
can
even
build
something
with
engineering
productivity
on
if
we
want
simplifying
the
pipeline
on
that
specific
branch.
D
So
because,
if
you're,
using
always
the
same
Branch
or
same
Branch
pattern,
then
we
can
see
if
this
is
running
here
and
the
author
is
this
a
user
here,
then
this
is
a
merge
conflict
pipeline
whatever,
and
so
maybe
you
don't
want
to
run
danger.
Bottom
dangerbot,
probably,
is
something
that
will
screw
up
there
right,
because
the
when
I
was
doing
this
thing,
but
this
is
always
a
bit
of
a
follow-up
right.
It's
a
follow-up,
not
actually
something
we
want
to
do
immediately,
but
the
things
that
it
runs
every
hour
is
probably
I.
D
B
A
D
We
say
we
do
something
clever
like
there
are
these
three
new
changes
with
no
conflicts
and
we're
gonna
put
them
on
top.
We
are
basically
restarting
the
pipeline
every
hour
with
a
pipeline.
It
takes
around
one
hour
and
we
are
very,
we
are
risking
of
never
never
ending
right
so
well.
On
the
other
hand,
maybe
the
most
interesting
part
is
if
there
are
new
conflicts
on
those
new
comments
right,
if
there
is
a
way
to
detect
that
one,
maybe
it's
worth
to
I,
don't
know
spin
up
a
new
one
or
I.
D
D
And
then
I'm
gonna
stop
is
that
in
case
of
merge
conflict
you
go
back
commit
by
commit
until
you
find
something
that
is
not.
That
is
not
conflicting
right
so
that
you
start
from
head
say
it's
conflicting:
throw
away
head
minus
one!
Still
conflict
x,
minus
two,
no
conflict!
Then
you
push
that
and
you
create
the
merge
request
with
the
difference,
so
you're
kind
of
pushing
as
much
as
you
can
before
the
conflict.
C
B
Seems
like
the
the
like
sort
of
like
easiest
fast
start
is:
if
there's
already
that
branch
that
exists,
meaning,
there's
a
merge,
request,
open,
just
exit
the
merge
train
or
that
process
early,
because
we
know
that
needs
to
get
fixed
before
we
can
try
again.
Essentially,
okay,
that's
helpful
and
yeah.
That's
squash
commit
option.
C
B
C
Yeah
I
think
it
should
be
only
us,
because
we
are
the
owners
of
the
security
group
and
only
security
owners
can't
change
that.
D
C
C
A
C
The
security
Comics
commits
into
the
auto
deploy
Branch,
because
we
used
to
have
a
step
like
that
and
then
I
think.
Okay,
we
are
going
to
force
the
merge
request
to
be
only
one
committee,
because
otherwise
we
need
to
cherry
pick
all
of
the
commits,
and
then
that
takes
time.
So
perhaps
we
don't
need
it
anymore.
C
A
A
D
A
Because,
perhaps
because
I
know,
we
only
discovered
the
problem
of
squashing
reasonably
recently
and
I
wonder
if
it
might
be
worth
US
changing
the
settings
so
that
it's
just
a.
D
It's
yeah.
We
can
change
this
to
encourage
if
we
think
it's
important,
because
I'm
looking
yes
does
not
allow,
allow
encourage
and
require
so
we'd
encourage.
Checkbook
is
visible
and
is
selected
by
default,
which
means
that
it
will
be
on
forever
security,
merge
request,
but
we
can
change
it
and
I
think
if
it's
set
to
encourage
you
can
change
it
with
the
with
the
push
command
with
the
push
parameter.
D
Where
you
can
say
the
way
Steve
is
generating
the
pipeline
the
emerging,
because
you
can
have
extra
parameters
to
to
avoid
I,
think
disable
jet,
because
I
don't
know
encourage
being
on
by
default.
If
it's,
it
can
be.
C
A
Yeah
yeah,
that
might
be
a
useful,
separate
issue
as
a
sort
of
follow-up,
because,
okay,
it
it
I
mean
it
generates.
Well,
even
when
we
get
it
right
and
we
change
the
squash
setting
it's
work,
but
also
there's
definitely
times
where
we
missed
that,
and
then
we
have
to
go
through
this
whole
thing
again.
D
B
D
Also
another
thing
which
is
about
absec
approval,
which
is
kind
of
unclear
what
we
want
to
do
there
so
yeah
and
looking
more
on
the
general
process,
point
of
view
right.
This
is
a
targeting
master,
so
it
requires
abstract
approval.
I
do
it
does
make
sense
to
me
that,
because
the
conflict
isn't
something
that
is
affected
by
the
ongoing
security
release,
that
they
want
to
review
it,
but
are
they
doing
it?
A
D
A
So
great,
is
there
any
other
stuff
Steve
that
is
useful
for
us
to
go
through,
for
you.
B
B
So
and
there's
plenty
for
me
to
go
up
there
and
in
the
review
itself,
so
I'll
work
through
all
that
this
week.
A
Awesome,
probably
actually
just
one
question
so
I
have
it
straight
so
once
we
have
this
in
place
from
a
release,
manager,
manager,
perspective,
we'll
still
see
the
error
in
slack
and
then
separately
there
will
be
an
MR
that
will
have
a
ping.
Is
that
correct?
No,
no.
We
won't
have
the
arrow
in
slack.
D
A
B
D
D
B
D
B
Oh
yeah,
you're
right
yeah
I'll
have
to
think
about
that.
Then.
D
You
can
save
that
in
a
variable.
You
can
save
the
result
of
that
operation
in
a
variable
and
return
it
at
the
end,
but
otherwise
it
will
yeah.
B
A
Yeah
I
think
it's
absolutely
fine,
like
I
think
if
it's
a
a
ping
for
a
really
smart,
just
like
like,
let's
just
update,
release,
run
books
and
make
sure
release
managers
know
you
know
you,
you
potentially
are
getting
some
like,
like
urgents,
maybe
a
bit
too
much
work,
but
some
like
time,
sensitive
pings
that
you
would
probably
want
to
deal
with
instead,
yeah.
D
D
Let's
say-
and
this
will
also
be
a
problem
because
I
as
a
release
manager
will
not
be
in
the
position
to
figure
out
the
resolution
by
myself
and
then
I,
because
then
I
have
to
do
the
git
diff
get
blame
fine,
who
changed
that
in
the
content
of
the
security
release
and
being
those
authors,
so
maybe
failing
at
least
the
first
time
I
mean
if
you
find
that
emerging
was
already
there.
Just
don't
do
it.
It's
still,
you
know
a
good
option
because
Dennis,
okay,
it
failed
I,
should
have
a
merge
request
somewhere.
D
B
Think
I
should
be
able
to
I
think
I
should
be
able
to
grab
the
merge
request
link.
So
if
I
fail,
potentially
I
could
post
the
merge
request
Link
in
slack
we'll.
B
A
This
Grace
off
cool,
so
you
have
the
next
item.
C
So
this
is
in
a
demo,
or
perhaps
it
is
I
just
wanted
to
show
you
what
is
the
latest
status
of
the
internal
pilot,
so
this
can
either
be
a
demo,
a
discussion
but
either
way
I'm
gonna
share
my
screen
and
yeah.
C
So
we
have
been
running
the
internal
demo,
which
means
that
developers
are
now
enabled
to
merge
into
a
stable,
Branch
honestly
so
far
so
good.
What
I
do
every
day
is
to
check
the
stable
branches
for
the
projects
on
their
managed.
Versioning
then
I
also
check
if
any
merch
request
also
has
the
peak
into
label
and
then
notify
the
author
that
hey
that
enable
doesn't
have
any
effect
anymore.
C
I
also
check
the
announcements
issue
to
see
if
we
have
any
other
discussion
and
the
release
patch
pressure
to
make
sure
that
it
is
similar
to
the
merge
sequencer
I
am
listing
here.
So,
as
of
yesterday
I
haven't
reviewed.
Today
we
had
six
merch
requests
from
gitlab
that
are
already
merged
into
the
stable
Branch.
All
of
them
were
using
the
right
instructions.
They
were
using.
The
merch
of
course
template
some
of
them
required
to
Ping
quality.
Some
of
them
didn't
because
the
package
and
test
pipeline
didn't
fail.
C
At
least
half
of
them
were
already
released
in
the
security
release
from
last
week,
and
this
one
is
interesting,
because
this
is
actually
a
different
contribution.
So
Jay
we
had
our
first
Community
contribution
into
a
stable
Branch,
so
that's
nice,
and
also
we
had
two
from
charts
and
from
CNG.
One
of
them
is
severity
one.
C
In
this
case
it
is
not
required
to
Ping
quality,
and
this
was
already
reviewed
by
a
security
release.
They
are
already
released
in
the
security
release
and
also,
as
of
yesterday,
we
considered
some
of
them
were
already
merged,
but
we
had
another
two
from
gitlab
the
severity
two
they
were
using
the
correct
process
and
also
one
from
Omnibus
and
another
one
from
charts
and
regarding
the
ones
that
are
using
the
peak
into
label.
We
still
have
one
from
git
love.
C
I
have
notified
the
author
that
there
is
a
new
process,
so
they
are
aware
of
it,
and
we
have
three
merch
requests
from
Runner
and
one
Mr
from
charts
that
are
using
this
label.
In
this
case,
there
is
nothing
to
do
because
this
projects
use
that
label
independently
from
our
process,
so
they
have
the
independent
usage
and,
while
I
have
a
breakdown
for
each
day,
if
anyone
is
interested
in
taking
a
look
and
based
on
all
of
this,
I
have
made
some
observation.
C
C
We
can
confirm
that
all
of
them
are
in
the
current
version,
which
is
15
out
of
10.,
so
yeah
I
haven't
received
any
comment
about
from
Engineers,
stating
that
this
is
way
too
much
work
that
they
don't
like
the
way
it
is
now
honestly,
it
has
been
quite
straightforward
because
this
is
about
created,
merch
requests
and
gitlab
Engineers
are
very
used
to
that.
C
D
D
C
Yeah
I
think
in
the
long
run
something
that
we
should
have
as
a
reminder
that
hey
this
label
is
like
it
doesn't
have
any
consequence
honestly
right
now,
we
don't
have
many
of
them,
so
it
is.
It
is
not
super
necessary.
C
That
at.
B
Some
point
in
the
future,
because
I
see
that
you
mentioned
that
charts
is
using
it
separately.
So
I
wonder
if
if
we
want
to
rethink
removing
that
label
or
somehow
move
it
to
just
that
project
or
something
they.
D
C
Yeah
I
have
an
issue
for
this
about
deprecating
the
labels.
My
idea
was
to
start
to
stop
generating
them
after
16
or
16
16.1,
but
I
guess.
We
also
should
consider
other
projects
to
precisely
Runner
and
charts
I
think
the
easy
solution
is
for
them
to
start
creating
their
own
label
and
then
just
have
their
own
process,
but
yeah
up
to
discussion
so
far.
D
C
Questions
to
confirm
the
processes
right
we
have
received,
for
example
like
this
one
one
week
of
loading
which
they
were
summarizing
hey.
This
is
what
I
need
to
do
and
then
we
just
sort
of
confirmed
like
yes.
This
is
what
you
need
to
do
and
these
are
the
guidelines
Etc
and
then
they
also
question
came
a
question
about
jihu,
which
was
the
membership,
was
that
was
merged
and
then
some
feedback
about
enhancing
the
process
by
creating
a
quick
action
or
a
bot
based
on
the
labels.
D
C
Yeah
I
mean
even
there.
Perhaps
there
is
a
way
to
wait,
but
still
I
think
that
is
not
necessary
for
the
external
for
this
maintenance
policy
iteration
it
can
be
a
follow-up
or
yeah.
A
Let's
just
push
this
one
down
a
bit:
I
think
this
is
a
a
very,
very
nice
to
have
what
might
be
useful,
though
Myra
is
to
to
actually
follow
up
with
some
of
the
people
who
have
gone
through
and
merged,
and
actually
what
I
would
suggest.
Timing
wise,
I
would
say:
let's
go
ahead
and
get
our
first
patch
release
out,
because
I
think
from
our
from
a
delivery
perspective,
the
test
is
really
to
come,
which.
C
A
Can
we
package
and
test
the
package
we
get
generated
and
not
have
anything
unusual,
but
I
think
once
we've
done
that
we've
seen
the
kind
of
end
to
end,
let's
reach
out
to
some
people.
Who've
actually
been
involved
in
this
process
and
not
necessarily
to
say
like
what?
What
like,
what
would
they
want,
changing
or
or
that
sort
of
word,
but
it
might
be
interesting
to
just
find
how
did
they
find
it
compared
to
the
original
process?
A
B
B
B
B
But
I
don't
think
we
have
anything
set
up
to
list
those
in
the
blog
post
so
like,
for
example,
those
first
three
back
ports
that
were
released
with
the
security
release.
Did
they
end
up
in
a
blog
post
anywhere.
C
Yes,
they
did
I
had
to
do
that
properly,
but
actually
the
next
issue
that
is
ready
to
be
picked
is
to
have
a
way
for
us
to
send
absect
a
list
of
block
fixes.
D
Maybe
we
should
take
a
live,
merge
request
for
every
I
mean
we
have
the
automation
that
generates
the
blog
posts
with
the
three
thing
right.
So
maybe
we
should
revisit
this
and
having
as
a
live,
constantly
living,
merge
request
on
on
the
website
so
that
they
know
when
you
want
to
release
it's
the
list
is
there
so
when
you
merge
something
you
just
refresh
the.
C
D
A
A
C
D
So
basically,
at
the
end,
we
just
set
the
version
when
it's
final,
which
is
kind
of
the
blanket
on
the
thing,
the
version,
the
real
version
numbers
and
we
merge.
If
it's
a
patch
or
we
don't
do
anything,
appsec
did
release
and
then
we
need
something
to
just
clean
up.
The
thing
I
mean
it
can
even
be
the
the
thing
itself,
because
then
now
the
stable
branches
will
be
released.
So
the
next
run,
we
just
say:
there's
nothing
on
stable
branches
and
just
remove
I,
say
regenerate,
because
I
don't
think
it's
probably.
D
Because
that's
what
the
thing
is
doing,
it
just
gives
you
a
markdown,
so
you
just
override
the
file
over
and
over.
A
Yeah,
that
might
be
a
great
idea
because
it
certainly
feels
a
bit
odd,
actually
like
it's
more
work
for
us,
but
still
also.
It
feels
odd
that
a
Stage
Group
would
have
to
come
and
like
edit
some
text
with
us
and
then
we
put
it
somewhere
and
then
we
tell
someone
else
like
so
I
think
that
might
be
a
good
one
to
to
hunt
hand
off
yep.
A
Yes,
thanks
for
putting
this
like
summery
stuff
together,
Mary
I
appreciate
you
going
through
this
every
day
and
kind
of
keeping
track.
It's
definitely
really
really
interesting
to
kind
of
see,
see
the
progress.
That's
going
on
and
fincy's
going
to
reach
out
as
well
to
Quality
and
just
there's
been
no
complaints
from
about
the
process
or
anything
which
is
great,
which
is
going
to
also
just
check
in
and
just
make
sure
there's
no
concerns
there,
but
overall
I
think
yeah.
It's
looking
really
good.
A
But
yeah
our
first
patch
release
will
be
the
one
I'm
most
interested
in.
So
that's
gonna
be
very,
very
good
to
see,
see
timings
but
also
check
that
we
don't
get
anything
unexpected
from
these
mergers.
C
Yeah
I'm,
sorry,
yeah
I
think
we're
going
to
start
one
tomorrow,
most
likely
and
probably
get
it
out
tomorrow.
Like
summer
time
so
yeah.
A
One
question
from
my
side:
so
I
moved
this
meeting
back
a
bit,
but
I
know
it's
still
right
at
the
start
of
your
day.
It's
definitely
for
you,
my
wrap,
also,
probably
a
few
Steve
as
well.
Is
this
a
good
time?
Does
this
give
enough
time
to
prep
or
shall
I
find
the
time
it
would
probably
be
Thursday,
but
it
could
be
a
bit
later.
D
I
mean
it's
fine,
because
I
can
be
the
first
30
minutes
if
worse
for
everyone
else,
because
I
I
have
time
for
the
other
I'm
in
the
other
one
as
well.
But
just
as
a
note.
B
B
Fine
for
me,
Mondays
and
Tuesdays
I
generally
am
able
to
start
a
little
earlier
so
I'm
online.
Before
this.
A
Go
okay,
great
thanks
for
the
demos
and
yeah
shout
out
to
you
all
soon.