►
From YouTube: Continuous Integration (Verify) 12.4 Kickoff
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
Hey
everyone:
my
name
is
Jason
Lenny
and
I'm.
The
product
manager
for
gitlab,
CI,
CD
and
today,
I'm
going
to
be
talking
about
the
upcoming
features
for
a
continuous
integration.
We're
releasing
in
our
12.4
release.
First
up
is
protecting
the
gitlab
CI
ml
from
changing
by
developers.
What
this
feature
is
all
about
is
using
the
code
owners
file
to
set
a
number
of
owners
for
the
gate
level
CI
mo
and
then
require
their
approval
in
order
to
make
changes.
A
This
isn't
necessarily
a
typical
flow
that
you
would
want
in
every
project,
but
in
large
projects
with
a
lot
of
different
users.
It
can
be
easy
for
somebody
to
make
a
mistake
in
the
gate.
Lepsy
im1
cause
an
issue
that
impacts
the
way
production
deployment
works
so
on
so,
and
also
certain
organizations
have
a
actual
team,
that's
responsible
for
things
like
implementing
the
the
deployment
environment
path
and
all
of
that.
A
Excuse
me,
while
ensuring
also
that
everything
is
everything
that's
needed
is
running
and
that
we're
not
too
aggressively
cancelling
things
to
the
point
where
it's
hard
to
get
a
pipeline
through
the
next
section.
Here
is
two
related
changes
so
for
users
of
our
github
integration,
who
are
using
get
lab
CI
CD
with
github
repositories.
A
So
if
you
have
repositories
that
you
need
to
update
it'll
be
easier
to
go
back
and
update
all
of
those
in
bulk
via
simple
script,
ability
for
admins
of
instances
to
override
the
artifact
size
per
group,
so
we
found
that
some
users
of
pages
or
other
large
projects
on
self-managed
instances
need
a
little
bit
more
space.
We
have
a
limit
of
one
gig
on
get
lab
comm,
for
example,
but
we
don't
let
let
people
control
this
at
the
moment.
A
A
Finally,
but
next
up
is
supporting
variable
expansion
in
the
branch
property
at
Bridge
jobs,
so
bridge
jobs
are
great
and
they
let
you
trigger
related
pipelines,
but
they
were
missing
some
features
in
particular
variable
expansion
inside
of
the
branch
property
itself,
which
meant
that
for
users
who
needed
to
do
that.
As
in
the
example
here,
you
still
had
to
you
start
a
job
to
run
a
curl
command
to
trigger
the
thing
that
you
want
to
trigger,
which
adds
an
extra
you
know
short
delay,
while
the
new
runner
is
set
up.
A
So
this
will
eliminate
the
need
for
that
and
make
the
bridge
drops
a
little
bit
easier
to
use,
giving
the
pipeline
variables
in
the
URL
from
the
new
page.
This
is
just
a
little
quality
of
life
improvement
that
we're
excited
to
deliver
where,
for
example,
you're
going
to
be
able
to
generate
a
query
string.
Something
like
this
in
order
to
provide
variables
in
the
URL
directly.
A
So
if
you
have
like
bookmarks
that
trigger
builds
in
certain
ways,
this
will
make
your
make
it
easier
and
more
powerful
to
set
those
up
and
now
really
finally
documenting
how
to
set
up
manual
jobs.
So
it's
actually
possible
today
to
have
a
job
that
is
a
manual
job
that
can
only
be
run
by
somebody
who
is
related
to
the
that
environment
that
job
is
associated
with,
but
it's
really
unintuitive
on
how
to
do
that.
It's
a
feature
request.
A
We
get
pretty
frequently
to
add
the
ability
to
protect
manual
jobs
so
in
this
release,
we're
going
to
improve
that
documentation,
make
it
more
clear
how
you
do
this
and
and
yeah
just
make
it
a
little
bit
easier
to
get
this
set
up
and
and
use.
So
that's
it
for
our
12.4
release,
another
one
that
we're
excited
to
deliver.
If
you
have
any
questions,
feel
free
to
reach
out.