►
From YouTube: GitLab 15.4 Kickoff - Verify:Runner
Description
Gitlab 15.4 kickoff overview for the Runner Group.
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28943
A
B
Thanks
darren,
all
right
I'll
start
sharing
my
screen
and
as
a
reminder,
just
as
a
reminder
of
what
runner
fleet
does.
Our
vision
is
to
be
able
to
provide
one
view
where
you
can
configure,
manage
and
use
some
type
of
monitoring
and
predictive
analytics
to
administer
your
fleet
of
runners,
and
you
probably
already
know
if
you
watch
these,
we
do
a
lot
of
work
in
both
the
admin
and
group
views
right
now
regarding
this.
B
So
that's
what
our
15-4
plan
really
focuses
on,
so
in
regards
to
features
that
we'll
be
working
on
this
milestone,
we're
going
to
be
finishing
up
bulk
delete,
which
is
really
exciting.
We've
heard
that
having
more
bulk
management
features
in
this
area
would
really
help
people,
especially
those
with
large
fleets
of
runners.
B
So
there
are
two
issues
here
that
we're
taking
on
where
you'll
be
able
to
select
multiple
runners
to
delete
in
the
admin
view
first
and
just
a
distinction
between
this
one
and
the
next
one
here
of
deleting
a
page
of
runners.
So
this
this
separate
issue
will
allow
you
to
select
all
runners
that
are
in
a
page
and
then
delete
them
at
once.
B
B
Some
other
issues
that
we're
taking
on
this
milestone
is
in
the
group
view
and
we're
really
excited
to
also
improve
and
focus
on.
The
group
runners
view.
So
we're
bringing
that
kind
of
more
up
to
speed
with
what
we've
been
doing
in
the
admin
view,
we're
using
a
refresh,
look
and
feel
that
we've
already
used
in
the
admin
view
so
that
they
are
more
consistent
and
then
another
big
one
that
we've
heard
from
customers
is
that
when
you're,
looking
at
group
runners,
you
don't
see
all
of
the
runners
that
are
available
to
you.
B
If
you're
in
a
project,
you
can
see
that,
because
you
can
see
all
the
shared
runners
group,
runners
and
project
runners
that
you
can
use.
So
this
issue
is
to
be
able
to
see
all
those
that
are
available
to
you,
so
that
you
know
exactly
which
runners
you
can
use
and
then
for
the
ux
type
of
stuff
that
we're
gonna
be
working
on
this
milestone,
we're
carrying
over
the
category
maturity
scorecard,
and
we
will
be
continuing
to
run
the
sessions
this
milestone
and
we'll
have
this
completed
by
then.
B
So
we
will
officially
have
a
maturity,
score
which
we're
very
excited
about,
and
then,
lastly,
we're
also
going
to
be
adding
a
design
for
the
stale
runner
cleanup,
setting
that
we
added
we
added
this
recently
for
a
group,
and
there
is
no
like
setting
to
be
able
to
toggle
this
on
and
off.
So
we
want
to
just
be
able
to
add
that
in
so
that
you
have
more
customized
customization
over
when
you
want
this
on
or
off,
and
that
is
pretty
much
it
I'll
I'll
hit
it
back
over
to
darren.
A
Hey
thanks:
you
can
find
a
toggle
button
there
for
a
second,
so
I'm
going
to
cover
the
other
two
runner
group
categories.
First,
starting
with
one
of
all,
you
just
kind
of
expand.
My
screen
here
for
a
bit
and
zoom
in.
Hopefully
this
is
legible.
So,
thanks
to
the
pump
gina,
this
is
the
direction
page
for
runner
core
and
just
as
a
quick
reminder
again
on
a
call
is
sort
of
the
little
engine
that
makes
all
of
this
stuff
works.
So
you
can
read
our
version
here
on
the
division
page.
A
Just
summarize,
we
kind
of
I
kind
of
think
about
this
as
being
split.
Bringing
like
half
of
our
brain
is
thinking
about.
What
does
the
future
look
like
for
our
build
agent?
How
can
we
improve
it?
How
can
we
make
things
more
automated?
How
can
we
get
to
zero
friction
state?
So,
at
the
end
of
the
day,
we
still
need
to
provide
a
compute
host
in
order
to
execute
these
ci
jobs,
and
there
are
so
many
different
options.
A
It
could
be
a
firecracker
type
virtual
machine,
but
at
the
end
of
the
day
that
stack,
that
atomic
concept
of
ci
job
needs
to
run
somewhere
and
so
part
of
our
brain
is
thinking
how
to
improve
what
we
have
in
that
hole
on
an
engine
so
that
we
can
make
life
as
simple
as
possible
for
our
users
that
have
to
self-manage
runners
and
obviously
for
gitlab
sas.
We
aspire
and
we'll
talk
about
the
direction.
A
It's
far
to
provide
everything
you
need
with,
so
that
you
don't
have
to
go
and
get
lab
sas,
but
significant
percentage
of
our
user
community
and
our
customer
community,
and
even
for
some
customers
in
the
website.
They
have
to
install
and
manage
their
own
owners
for
various
reasons,
and
so
we're
thinking
about
what
does
that
landscape
look
like
in
the
future?
So
you
go
to
our
direction
page,
that's
what
that's
talking
about
so
happy
world
breeder
and
half
of
our
conversations
are
about
that
future
and
improvements.
A
The
ns
is
where
we
and
now
take
your
attention
over
to
our
iteration
plan
for
15,
for
right,
so
with
one
on
one
side,
we're
thinking
big
picture,
what
can
we
do
to
improve
things
and
in
a
day-to-day
we've,
just
got
to
keep
the
current
engine
working
as
efficiently
as
possible.
So
in
15-4
we're
doing
a
bunch
of
works,
continuing
our
focus
on
our
bug
burn
down.
A
We
still
have
a
large
backlog
of
bugs
that
we'd
like
to
get
through
specifically
bulbs
marked
severity,
2
and
priority
2..
We
want
to
continue
to
burn
those
down,
and
so
you
see
a
lot
of
investment
here
in
15400
worlds
and
that's
what
I'm
gonna
recall.
A
lot
of
features
here
are
bugs
in
terms
of
new
features.
A
Their
continuous
masking
of
mass
variables
is
heart
of
the
presses,
but
this
looks
like
it's
very
close
to
being
shipped
in
one
of
four
just
want
to
draw
your
attention
to
that.
That
is
a
significant
change
to
the
regular
creation
feature
in
ronald
call,
and
so
take
a
look
at
that.
If
mass
variables
are
interesting,
some
that
you've
been
waiting
for
in
terms
of
net
new
features,
we
are
actually
working
on
not
a
whole
lot
in
terms
of
new
capabilities
in
154.
A
There's
some
maintenance
work
plan
in
terms
of
keeping
our
helper
images
and
base
images
up
to
date,
so
that
we
have
less
issues
with
the
out
of
sync
with
versions
that
may
have
cv
vulnerabilities
and
those
types
of
things
and
then
there's
some
dependency
work
so
call
from
some
maintenance
work.
The
one
new
feature
capability
is
more
than
likely
going
to
be
the
shipping
of
the
continuous
masking
of
mass
variables,
and
then
the
bulk
of
the
remaining
investment
is
on
these
bulk
that
we
have
identified.
A
You
want
to
try
at
least
burn
through
some
of
these
septum
bugs
here
on
this
list
in
54.
The
other
category
in
runner,
in
the
record
in
the
running
group,
is
runner
sass,
everyone
assass
just
a
quick
recap.
If
you're
on
github.com
we're
doing
the
free
plan
premium
plan
ultimate
time.
If
you
are
using
github.com
by
default,
you
have
take
advantage
of
the
sas
runners
that
are
offered
in
gitlab.com,
and
so
our
vision
there
is
to
provide
you
on
github.com
as
as
much
as
possible.
A
Some
of
the
big
ticket
items
we're
working
on
will
be
offering
multiple
machine
or
resource
types
for
our
linux
runners,
specifically
our
linux
runners
that
run
the
ci
job
in
a
containerized
or
very
specifically,
a
docker
container
environment
and
most
of
the
our
users
take
advantage
of
that.
If,
if
you're
looking
at
this
video
for
the
first
time
and
our
documentation
doesn't
seem
super
clear,
let
me
just
kind
of
iterate
this.
A
If
you're
on
github
sas
you're
creating
your
first
pipeline
on
github
sounds
for
the
very
first
time
you
don't
have
to
do
anything
in
order
for
your
first
pipeline
job
to
run
our
sas
release
and
linux
are
set
up
to
automatically
run
any
job
on
get
that
com.
That's
not
tagged,
so
you
can
immediately
take
advantage
of
these
science
runners
and
what
we're
delaying
long
term
and
this
match
this
feature
here,
may
actually
ship
in
153.
It
may
bleed
over
to
15-4,
even
though
I'm
not
talking
about
on
the
iteration
plan.
A
We
are
adding
additional
google
compute
machine
types
to
the
catalog
for
the
sas
runners
that
are
on
linux
and
specifically
run
your
jobs
in
a
docker
container
environment,
but
popping
over
to
the
15
for
iteration
plan
for
sas
aside
from
adding
additional
compute
times,
and
that
will
be
ongoing.
Taylor
153
may
be
bleeding
to
154,
specifically
in
fifteen
four
there's
an
other
work
that
we
need
to
do
that's
part
of
our
long-term
strategy.
A
So
what
we
hope
to
get
to
in
fifteen
and
four
is
studying
some
work,
that's
related
to
supporting
our
strategy
of
moving
our
linux,
shared
runner
architecture
or
scaling
architecture
to
what
we're
calling
our
next
runner
scaling
platform,
and
that
sets
the
foundation
for
our
self-managed
customers
that
are
needing
to
move
off
of
our
legacy.
Auto
scanning
technology,
that's
based
on
the
docker
machine.
So
that's
what
these
two
things
here
are.
A
First
on
gitlab
sas
internal
runners,
the
runners
that
we
use
internally.
So
we
can
dock
through
that
and
then
later
on,
that
same
feature
set
after
we've
handed
it
at
scale
here
on
github.com
will
then
be
released
to
the
customer
user
community.
So
you
can
start
taking
advantage
of
our
new
auto
skating
technology.