►
A
Hi
everyone,
my
name,
is
tal
yaeger,
I'm
a
product
manager
here
at
gitlab
for
continuous
integration,
and
today,
I'd
like
to
highlight
a
few
features
that
we'll
be
working
on
in
release.
13.10.
first
feature
that
I
want
to
talk
about
is
adding
a
project
setting
to
allow
merges
before
pipelines
complete.
Now.
When
would
you
ever
need
that?
A
Basically
that's
how
the
current
behavior
is
for
for
our
product,
but
you
don't
have
the
ability
to
disable
this
so
the
currently,
we
have
the
ability
to
merge
immediately,
and
this
is
very
valuable
when
you
need
to
urgently
merge
a
high
priority,
merge
request.
Even
if
you
have
merge
results,
pipelines
enabled
or
pipelines
merge
trains
enabled
as
well.
A
A
So
what
are
we
going
to
do
to
solve
for
this
we're
introducing
a
new
project
setting
that
is
enabled
by
default
and
the
reason
it's
enabled
by
default?
Is
it
allows
the
current
behavior
of
letting
you
merge
your
mr
using
the
merge
immediately
button,
a
slash,
merge,
quick
action
or
an
api
call.
Nothing
will
change
with
the
introduction
of
this
new
project
setting.
A
Moving
on
to
the
next
feature
that
I
want
to
highlight
for
13.10
is
the
ability
to
merge
your
merch
request.
If
your
pipeline
is
empty,
even
if
you
have
pipeline
must
succeed,
enabled
the
problem
we're
trying
to
solve
here
is
having
a
project.
Setting
of
pipeline
must
succeed,
enabled
if
you
have
a
scenario
where
no
pipeline
runs,
you
would
never
be
able
to
merge
that.
A
A
You
would
never
be
able
to
merge
that,
mr
because
the
ci
confused
with
evaluate
to
all
jobs
being
skipped
because
there's
no
changes
to
directory
a.
However,
in
the
with
all
jobs
being
skipped,
it's
an
mt
pipeline
and
the
absence
of
this
pipeline
running
would
never
satisfy
the
condition
that
pipelines
must
succeed,
and
so,
therefore,
that
that
mr
to
make
changes
to
director
b
can
never
be
merged
based
on
how
our
settings
is
configured
today.
A
So
what
we
are
going
to
introduce
in
this
new
feature,
it'll
be
a
two-part
implementation.
The
first
iteration
in
13.10
is
to
allow
you
to
to
it's
to
introduce
a
new
project,
setting
that
looks
for
the
presence
of
a
pipeline,
and
you
have
the
ability
to
enable
or
disable
this
through
api
as
the
first
implementation,
and
in
doing
so
we
would,
it
would
check
to
see
if
there
was
a
mr,
that's
being
prepared
and
ultimately,
even
with
an
empty
pipeline.
A
A
third
feature
that
we'll
be
working
on
that
we've
mentioned
in
the
past
and
it's
again
scheduled
for
13.10,
is
to
give
you
the
ability
to
bulk
delete
artifacts
through
an
api.
Currently,
the
only
way
to
delete
artifacts
is
individual
individually,
and
we
have
an
api
to
support
that.
But
there
is
no
method
to
do
a
bulk
delete
of
artifacts,
and
so
in
providing
this.
A
A
In
the
example
that's
given
here,
I
won't
run
through
it
in
detail.
You
can
read
it
for
yourself,
but
what
it
turns
out
is
the
parent
pipeline
correctly
evaluates
variable
priority.
In
this
case,
it
looks
at
this
globally
defined
variable
in
the
yaml,
and
it
knows,
and
that
would
be
priority
looking
at
the
documentation
here.
A
That
would
be
the
priority
number
seven,
but
in
that
example
it
it
is
letting
the
scheduled
pipeline
variable
override
a
lower
priority,
a
variable
defined
in
the
yaml,
but
when
it
comes
to
the
child,
somehow
the
child
pipeline
is
doing
the
opposite.
It's
allowing
this
variable
defined
in
the
yaml
to
override
a
scheduled
variable
which,
obviously,
in
in
this
documentation,
takes
out
of
order
the
precedence
of
variables
variables
listed
at
top
being
higher
precedence
and
should
override
anything
below
so,
hopefully
fixing.