►
From YouTube: Adding an MR back to the merge train with MWPS enabled
Description
Discussion to come up with a solution to the problem - users are not being able to re-add an MR to a merge train when the merge train pipeline does not complete successfully causing the MR to drop from the train.
A
All
right,
so
this
meeting
is
mostly
to
get
some
clarification
around.
What
is
the
sequence
of
not
improvement,
but
preparation
that
we
want
to
do
in
order
to
provide
a
holistic
solution
to
the
issue.
That
is
that
this
meeting
is
about,
which
is
users
cannot
react.
Merge
requests
to
a
merge
train
when
pipeline
must
succeed
is
enabled
so
right.
A
But
it
seems
like
at
this
stage
that
that
is
not
an
ideal
way
to
go
about
it,
and
the
concerns
have
been
recorded
in
the
comments
in
the
issue,
and
so
I
just
wanted
for
us
to
have
like
another
round
of
discussion,
taking
into
account
where
we
have
reached
so
far.
Like
all
the
discussions
that
have
already
happened.
What
is
the
conclusion
from
that
and
how
we
can
take
our
learnings
from
there
and
reconstruct
our
path
forward?.
A
So
in
the
agenda,
I
have
like
just
put
the
problem
statement
so
that
we
have
that
in
our
at
the
top
of
our
mind
before
we
like
talk
about
anything
else
and
the
main
questions
that
we
would
want
to
be
looking
at
today.
The
first
one
is
that
what
are
the
big
backend
capabilities
required
to
achieve
a
solution
for
this
problem
and
where
we
are
today
like
at
this
point?
B
B
If
the
pipeline
is
not
for
merger
request
could
be
merged,
train
could
be
merged,
requests
could
be
detached,
merge
requests,
so
we
have
to
use
this
val
this
data
to
distinguish.
Whether
is
the
pipeline
that
we
are
seeing
in
the
widget
a
merge
request
pipeline.
Then
it
is
a
user
trigger
pipeline
and
we
should
do
whatever
we
do
today.
B
But
if
it's
a
merge
request
pipeline-
and
we
need
then
to
display
the
react
to
merge
too
much
train
button
and
adjust
the
messaging
depending
whether
the
pipeline
is
failed
or
or
canceled,
and
but
we
do
need
this
data
point
of
what
is
whether
the
latest
pipeline
is
merged.
Request
pipeline,
because
we
currently
provide
these
in
the
serializer
from
back
end
to
front
end.
But
I'm
not
sure
whether
the
front
end
is
still
using
the
same.
Endpoint.
C
Yeah,
so
my
contacts
isn't
the
best
right
now
around
merge,
request,
widgets,
but
I've
been.
It
was
my
first
time
working
on
it
and
the
same
with
merge
strains,
but
I've
done.
I
did
a
little
bit
of
digging
through
the
code
and
it
seemed
that
we
are
now.
We
do
now
have
graphql
in
it
and
that's
we.
We
have
the
legacy
version,
that's
using
the
rest
endpoint,
and
then
we
have
the
feature
flag,
which
I
posted
a
link
in
the
agenda.
C
B
B
B
Otherwise
we
just
live
barely
behavior
as
it
was
before,
and
ideally
all
this
behavior
should
come
from
the
back
end
like
what
action
can
the
user
can
perform
and
and
what
message
should
be
displayed
and
then
front
end
should
be
able
to
take
the
action,
the
name
of
the
action
if
the
action
says
add
to
merger
request,
you
display
the
button.
I
have
add
to
merge
request.
B
If
we
do
it
in
the
front
end
now,
but
we
might,
we
need
to
open,
I
think,
technical,
that
issue
to
revisit.
This
eventually
can
move
back
to
the
back
end
as
as
well
as
a
lot
of
logic
that
I
think
painting
we
have
we've
discussed
in
the
past.
A
lot
of
logic
might
need
to
be
moved
to
the
back
end
but
yeah.
Maybe
that
could
be
an
excuse
to
start
moving
stuff
back
to
the
back
end.
C
C
C
B
C
B
B
B
If
that
fails,
everything
else
after
that
and
all
the
measure
quests
are
dropped
from
the
track.
Well,
not
kind
of
dropped,
it's
not
the
actual
term,
but
it's
we
restart
a
new
pipeline,
so
the
pipeline
that
was
running
is
cancelled
automatically
a
new
one
is
created
because
the
merge
train
is
rebuilt.
B
We
are
considering
the
latest
pipeline,
like
a
merger
request
pipeline
and
if
the
merchant
respect
line
is
failed
or
is
cancelled.
Basically
it's
not
unsuccessful.
You
cannot
merge
it
because
the
pipeline
must
succeed.
The
project
setting
was
enabled
so
because
we
are
looking
at
the
nurturing
pipeline
like
it
was
triggered
by
the
user
with
a
bit
push.
For
example,
we
are
telling
the
user,
no,
you
cannot
continue,
because
this
pipeline
is
not
successful
and
but
the
user
is
telling
us,
but
this
pipeline
is
created
by
the
system.
This
is
not
created
by
me.
B
This
is
the
reason
why
I
think
we
need
to
distinguish
based
on
the
pipeline
event
type
that
tells
us
this
is
actually
a
magic
request
pipeline.
So
it's
actually
system
created
merger.
Something
automatic
is
not
created
by
the
user.
So
if
the
user
arrived
to
the
point
of
creating
a
merge
request,
a
merged
train
pipeline,
it
means
that
we
that
the
merge
request
the
latest
pipeline
for
merge
request
was
successful
because
we
allowed
basically
to
be
merged
and
and
to
be
able
to
go
to
the
merge
string.
I'm
not
sure
like.
C
B
Okay
might
have
to
go,
create
a
new
run,
a
new
pipeline,
and
when
that
passes
they
can
actually
add
this
to
the
merge
train,
because
when
the
pipeline
is
successful,
we
are
allowed
to
be
added
to
nurturing,
but
it's
actually
the
successful
pipeline
is
already
for
merged.
It
is
already
a
merge
train
pipeline,
so.
C
Yeah,
because
I
was
looking
at
the
logic
and
the
current
implementation
logic
is
determining
if
we
display
the
state
of
you
know:
hey
this
pipeline's
failed,
no
matter
what
it
just
takes,
the
latest
pipelines
data
and
see
if
the
status
is
failed
or
cancelled.
Yes,
so
if
you
accidentally
remove
a
merge
train
from
a
merge
request
from
the
train,
it's
automatically
canceled,
you
know
by
by
implementation,
so
we're
automatically
going
to
show
that
right
now.
C
C
B
C
B
Yeah
yeah,
okay,
so
there
is
a
table.
So
if
you
look
at
the
mythical
you
linked
the
recent
discussions,
this
you
know
in
the
issue.
This
is
the
latest
comment
there.
On
the
on
the
issue
like
I
provided
a
table,
there
basically
describe
the
use
cases
so,
depending
on
the
pipeline
event
and
the
pipeline
status.
What
could
be
the
button
and
what
could
be
the
message
so
we
need
to
so.
B
B
B
And
yeah,
so
the
thing
is
like:
if
it's
not
a
merger
request
a
multitrain
pipeline,
so,
for
example,
merger
result
pipeline
in
this
case,
whether
it's
failed
or
america
or
or
cancelled.
We
treat
it
the
same
way,
because
that
is
the
logic,
and
I
think
this
is
still
valid
if
it's
merge
request
pipeline.
B
But
if
it's
a
managed
training
in
both
cases,
we
still
have
to
display
the
auto
merger
button,
but
the
messaging
might
be
different
because
a
failure
could
be
caused
by
something
wrong
in
the
source
branch
or
something
wrong
with
the
target
branch.
Sometimes,
if
it's
something
wrong
in
the
target
branch,
it's
like
there's
a
failure
of
master,
for
example,
and
you
get
some
failing
tests
because
there
is
a
failure
remastered.
B
A
B
B
D
A
B
I
think
what
might
be
missing
is
the
the
pipeline
event
so
the
first
column.
What
is
the
merge,
train
pipeline
or
merge
request
pipeline?
The
graphql
that
the
front-end
uses
might
be
missing
this
data,
so
we
will
not
be
able
to
distinguish
it
between
the
mesh
train
versus
mercury
request
pipeline,
and
this
is
important.
A
All
right
so
once
that
is,
if,
if
we
put
things
in
sequence,
that
means
first
we'll
have
to
work
on
pipeline
events,
and
then
we
can
think
about
creating
a
solution.
I
mean
it's
pretty
easy.
It's
going
to
be
a
very
like
simple
messages,
but
for
that
we
need
to
build
this
capability
first
and
then
work
on
that.
A
D
A
D
D
B
D
D
B
A
The
slash
merge
actually
fixes
this
problem,
but
we
are
not
putting
it
on
the
ui,
so
that
I
mean,
if
we
put
it
on
the
ui,
we'll
have
to
give
a
very
long
explanation
or
like
we
would
have
to
guide
the
users
around
like
identifying.
If
this
was
a
merge
string
pipeline
versus
if
it
was
not-
and
I
don't
know
how
that
is
going
to
pan
out.
D
C
We
should,
though,
be
able
to
differentiate
what
they're
doing
after
the
back
end
is
in
place
like
we'll
be
able
to.
You
will
be
able
to
say,
okay,
this
user's
on
a
merge
train
pipeline
this.
They
need
help
with
this
or
they're
on
a
merge
result
pipeline.
So
we
could,
we
could
have
seen
you
know
we
could
have
dedicated
messages.
D
A
B
C
I
don't
think
we
do
because
the
first
time
I
started
like
messing
around
with
this
a
few
weeks
ago,
like
creating
more
stream
pipelines,
I
was
super
confused
when
I
went
to
the
pipelines
tab
because
I
was
like
wait
which
pipeline
was
it,
but
the
only
way
I
could
differentiate.
It
is
because
I
knew
how
many
stages
I
had
in
each
pipeline,
so
I
was
like
okay.
B
D
D
C
D
I
I
think
so
so,
depending
yeah,
the
messages
be
something
like,
depending
on
the
type
of
pipeline,
you
have
go,
go
to
the
docs
to
know
what
your
possible
actions
are
and
then
that
will
just
yeah.
That
would
be
the
end.
The
I
don't
even
want
to
call
it
the
nbc.
That's
just
like
the
stop
gaps,
solution,
yeah.
C
A
D
D
So
so
what
I'll?
So
what
I
was
suggesting
is
I
we
still
move
forward
with
the
ui
instruction,
just
the
text
update
in
13.9,
along
with
another
issue,
to
label
the
pipelines,
whether
it's
a
merge,
sharing,
pipeline
or
or
other
not
the
word
other,
but
I'll.
Let
rita
could
come
up
with
that.
So
so
you
know,
and
maybe
we
clearly
also
call
out
when
it's
a
merge
results
pipeline,
and
you
know
just
a
just
a
merge
request
pipeline,
I'm
probably
a
left
and
I
have
to
run
to
another
meeting.
D
Let's
let
me
follow
up
with
a
question
for
him.
If
let
me
see
if
I
can
find
that
issue,
but
vitega
know
that
the
long
term
solution
I
moved
to
1310
and
so
you'll
have
to
design
you
have
to
design
both
for
that
issue
of
how
to
label
the
pipelines
and
then
the
text
of
the
ui
instructions.
We
want
to
update
for
13.99,
okay,
all
right
yeah,
but
I'll
do
some
of
that
after
my
next
meeting
rearranging
them.
Okay,
thanks
folks
and.