►
From YouTube: GitLab 14.4 Kickoff - Verify:Pipeline Execution
Description
Welcome to Verify Pipeline Execution14.4 Kick Off! This group is responsible for GitLab CI, such as pipelines, pipeline processing, as well as the category of Merge Trains. In 14.4 we are focused on reliability and SaaS availability as well as CI Minutes to prevent pipeline abuse.
A
Welcome
to
the
verify
pipeline
execution,
14.4
kickoff,
my
name
is
jackie
porter,
acting
product
manager
for
the
pipeline
execution
group
here
at
git
lab
and
I'm
joined
here
with
vitica
the
product
designer
for
the
group
as
well.
This
group
is
responsible
for
gitlab
ci,
which
is
the
overall
pipeline
and
pipeline
processing
experience,
as
well
as
the
category
of
merge
trains
in
14.4.
We
continue
to
be
focused
on
the
reliability
and
sas
availability
theme,
as
well
as
ci
minutes
to
prevent
pipeline
abuse.
A
A
project
pipelines
controller,
which
has
a
lot
of
volume
related
to
a
database,
call
account.
What
we
will
do
is
reduce
this
volume,
which
will
help
impact
our
error
budget
for
the
pipeline
execution
team.
The
second
infra-death
issue
that
we'll
be
prioritizing
is
related
to
the
creation
of
a
new
pipeline
on
gitlab.com,
which
currently
has
an
experience
that
is
very
slow.
A
The
flow
here
is
that,
once
you
create
a
pipeline,
the
current
experience
is
that
it's
a
super
slow
reported
at
24
seconds.
Currently
this
shouldn't
be
going
so
slow,
so
the
proposal
here
is
to
target
this
particular
controller
and
optimize
that
controller
for
our
users
to
stop
experiencing
that
error.
B
Okay,
thanks
for
that,
jackie
and
since
I've
already
mentioned
the
areas
I'll
dive
right
into
the
issues.
The
first
one
is
return
warnings
in
job
logs
when
ci
job
token
is
used
without
the
secure
workflow
being
enabled.
So
when
say
a
job
token
is
used
without
the
secure
workflow
enabled
we
are
not
providing
any
warnings
to
users,
and
we
want
to
do
that,
and
we
want
to
do
that
so
that
they
can
look
towards
enabling
the
secure
workflow
and
even
if
they
want
to
adopt
an
alternative
for
that.
B
Yeah,
the
next
one
is
show
your
nci
minutes
usage
graph.
So
very
recently,
we
rolled
out
a
ci
usage
graph
for
that
shows
the
ci
usage
historical
data
by
month
and
project
on
the
ci
cd
analytics
page,
but
it
doesn't
mention
the
year
and
neither
does
it
take
into
account
the
guidelines
for
refreshing
the
data
when
the
year
is
updated.
B
That's
what
we'll
be
adding
as
a
part
of
the
solution
and
so
we'll
add
a
provision
in
the
ui
for
including
the
year
with
the
month
and
also
define
the
behavior
about
how
you
can
access
the
data
from
the
previous
years
moving
to
the
next
one.
This
is
pipeline,
more
actions
showing
empty
drop
down
pen
script.
So
we
very
recently
made
this
change
where
we
move
the
download
artifact
action
inside
a
kebab
menu.
This
was
to
improve
the
performance
of
the
pipeline
index
page
and
slowly.
B
We
are
taking
up
issues
to
improve
the
usability
of
this
interaction,
so
we'll
be
adding
sort
of
an
empty
state
as
a
part
of
this
issue
when
there's
no
download,
no
artifacts
to
download,
of
course,
yeah
thanks,
jackie
yeah.
And
lastly,
since
we
have
made
many
small
changes
to
the
pipeline
index
page,
they
were
all
very
small.
But
eventually,
since
we
made
many
of
them,
we
would
really
want
to
get
in
touch
with
our
users
to
understand.
If
we
are
not.
B
If
we
are
diverging
from
a
good
user
experience
or
if
they
are
finding
those
changes
useful
and
if
the
layout
is
usable
for
them
and
everything
all
the
primary
actions
that
they
have
been
looking
that
they
have
been
performing
using
the
pipeline
index,
page
they're
still
able
to
perform
that.
A
A
As
noted
in
our
introduction,
our
second
primary
focus
beyond
reliability
is
going
to
be
on
ci
minutes,
so
we
have
this
back
end
issue
related
to
counting
the
duration
of
shared
runners
separately
from
ci
minutes
for
viewing
that
consumption
in
our
in
our
product.
So
this
is
particularly
important,
because
users
will
then
have
a
way
to
have
an
accurate
accounting
of
their
duration,
their
consumption
of
ci
before
we
enforce
a
ci
minute
limit,
which
is
a
subsequent
iteration
in
our
in
our
in
our
life
cycle
for
gitlab.com.
A
This
is
a
mitigation
effort
for
the
pipeline
abuse
work
that
we've
started
back
in
early
january
when
we
started
having
a
spike
in
crypto
mining
abuse.
So
this
is
a
a
step
in
in
that
path
for
enforcing
ci,
minute
limits,
and
this
will
hopefully
help
users
and
everyone
get
better
visibility
into
their
ci
minute
and
duration
consumption.