►
From YouTube: GitLab 13.0 Kickoff - Verify:CI
Description
https://gitlab.com/gitlab-org/ci-cd/continuous-integration/-/issues/1
- https://gitlab.com/gitlab-org/gitlab/-/issues/15268
- https://gitlab.com/gitlab-org/gitlab/-/issues/16267
- https://gitlab.com/gitlab-org/gitlab/-/issues/22638
- https://gitlab.com/gitlab-org/gitlab/-/issues/15122
- https://gitlab.com/gitlab-org/gitlab/-/issues/14108
A
Everybody,
my
name
is
Kenny
Johnson
I'm,
the
Senior
Director
of
Product
Management,
forget
lab
covering
the
ops
section.
That's
the
verify
package,
release
configure
and
monitor
stages.
I'm,
actually
here
subbing
in
for
at
a
Jaeger,
are
awesome
p.m.
covering
the
CI
Group
in
the
verify
stage,
I'm
going
to
be
performing
the
kickoff
video
in
her
stead,
while
she's
out
on
ppm,
so
I'm
gonna
share.
My
screen.
A
I
will
just
start
with
the
fact
that
I'll
add
links
to
the
specific
issues
and
the
planning
issue
I'm
about
to
show
in
the
description
of
this
video,
but
obviously
I
am
NOT.
An
expert
like
Tao
is
so
please
bear
with
me
in
my
overview.
Ok,
so
this
is
the
planning
issue
for
the
CI
group.
The
top
five
Direction
issues
are
linked
here,
I'm
going
to
go
through
them
one
by
one,
not
necessarily
in
this
order.
I'll
start
first
with
filters
for
pipelines.
A
So
if
you've
ever
interacted
with
gitlab
pipelines,
I'll
just
show
you
live
what
it
looks
like
for
the
lab
project.
This
list
is
large,
not
filtered,
starts
with
all
it's
difficult
to
navigate,
especially
in
projects
with
lots
of
different
pipelines.
So
what
we're
planning
on
adding
in
13o
is
the
ability
to
filter
those
pipeline
views.
A
So
there's
some
great
mock-ups
here
of
what
that
would
look
like
with
a
kind
of
standard
give
up,
filter
bar,
and
the
thing
that
I
want
to
highlight
is
that
our
top
two
priorities
for
this
filter
and
this
release
things
that
we're
going
to
make
sure
we
get
in
in
the
first
iteration
are
trigger
author
and
branch
name.
Those
are
the
most
popular
and
highest
priority.
You
can
see
some
examples
of
the
status
trigger
author
view
trigger
source
and
then
a
general
search
where
you
would
use
something
like
the
branch
name
to
filter
your
pipelines.
A
A
So
this
feature
will
allow
users
to
specify
to
keep
the
latest
artifact
in
their
CI
a
UML
file,
and
only
that
latest
artifact,
thus
keeping
their
their
storage
costs
down.
The
next
one
is
about
inheriting
environment
variables
from
dependent
jobs.
So,
as
the
issue
describes
today,
you
can
store
various
content
artifacts
in
content
in
artifacts
and
then
pass
them
between
jobs,
but
that
can
be
pretty
heavy-handed.
If
really
all
you
want
is
a
kind
of
like
single
there
about
the
example
here
being
the
build
version
that
you're
creating
in
the
build
stage.
A
You
want
to
make
sure
that
that
is
referenced
in
the
in
the
deploy
stage,
so
we'll
be
adding
this
support
for
passing
them
between
passing
them
with
this
M
keyword
between
stages
in
get
lab.
The
next
issue
for
1300
for
the
the
CI
group
is
excluding
paths.
So
when
you
create
cash
or
an
artifact,
you
typically
define
paths
that
you
want
to
create
that
artifact
from.
A
But
you
can't,
you
can't
use
an
accept
or
you
can't
do
a
not
I
want
everything
and
build,
but
not
this
other
folder
for
in
this
example
right
here
and
so
we'll
be
adding
the
ability
to
do
just
that
by
not
having
this.
It
causes
a
causes.
Users
pain
of
having
to
list
every
single
specific
folder
within
that
folder
that
they
do
want,
as
opposed
to
the
converse
and
in
cases
of
build
folders.
That
can
be
quite
large
and
quite
onerous
as
the
folders
change.
A
So
this
allows
this
would
allow
users
to
kind
of
easily
exclude
specific
paths
that
they
know
they
don't
want
to.
You
include,
you
know,
Thanks,
there's
a
good
example
here
below
that
I
was
noticing
of
kind
of
having
a
not
operator
in
the
past,
something
like
that
and
then
the
last
issue,
Direction
issue
for
the
the
CI
group
in
13
ATO,
is
adding
global
CI
variables
global
instance
level
variables
for
your
CI
job.
So
today
you
can
define
these
variables
at
the
project
and
group
level.
A
We
went
to
enable
you
to
have
CI
variables
at
the
instance
level.
So,
as
you
define
these
and
these
variables
for
your
CI
builds,
there
are
lots
of
use
cases
for
having
kind
of
global
credentials
the
primary
example
being
you're
like
deployment
wholesale
deployment
or
docker
registry
keys
that
you
wants
to
you
utilize
across
all
CI
pipelines,
but
protect
and
not
have
to
copy
them
across
all
groups
or
projects.
So
I'll
stop
sharing.