►
From YouTube: GitLab 15.9 Kickoff - Verify:Runner
Description
Runner group 15.9 kickoff video.
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29119
A
I'll
start
with
Runner
Fleet,
which
is
one
of
the
categories
within
the
runner
group
and
I'll,
share
my
screen
for
this.
So
This
Milestone.
We
will
be
again
just
focusing
on
trying
to
improve
the
experience
of
managing
a
fleet
of
runners
and
we
focus
mostly
on
the
admin
area,
but
this
Milestone
we
get
to
focus
on
the
group
area.
So
we're
very
excited
about
that.
One
of
the
features
that
we've
been
asked
a
lot
about
is
adding
jobs
to
Runner
details
for
groups.
A
So
now,
when
you
view
details
of
a
runner
when
you're
in
gitlab.com,
you
can
see
all
the
jobs
that
it
runs
and
get
more
information
about
the
queue
time
for
those
jobs
as
well
and
the
duration,
the
status
and
Etc.
So
we're
super
excited
about
that.
Another
issue
that
we're
going
to
be
working
on
is
improving
the
runner
creation
flow
and
we're
starting
just
with
the
admin
area
for
this
one.
A
So
this
relates
to
a
huge
effort
that
the
runner
team
has
been
working
on
in
the
back
end,
to
make
our
creation
flow
more
secure
and
just
improve
like
the
efficiency
of
it
in
general,
and
so
this
issue
is
actually
updating
the
UI
to
to
surface
this.
A
lot
of
what
we
can
do
now
will
be
in
the
UI
rather
than
having
to
be
prompted
in
the
CLI
for
a
lot
of
it.
A
You
still
will
have
to
go
to
the
CLI,
but
we
will
be
able
to
provide
a
lot
more
information
about
all
the
different
methods
that
you
can
use
to
create
a
runner
and
the
differences
between
executors
and
all
that
stuff.
So,
in
relation
to
this
I'm
going
to
skip
over
to
just
what
we're
working
on
in
ux
real
quick,
because
it's
related
we're
also
going
to
work
on
those
workflows
for
the
group
air,
the
group
View
and
for
projects
as
well
So.
A
B
Hey
thanks
a
lot.
You
know.
That's
super
awesome,
especially
the
group
view
stuff,
a
lot
of
customers
on
gita.com
that
are
still
that
imagine
your
own
ones
have
been
asking
about
it.
So
that's
really
cool
to
see
that
hey
everyone,
so
I'm,
just
going
to
briefly
cover
what's
happening
in
the
course
side
of
things
in
the
runner
group.
B
So
the
first
thing
I
just
want
to
call
your
attention
to
on
this
heading
here
called
Next,
Runner
token
architecture.
This
is
what
Gina
was
referring
to
when
she
was
describing
the
new
Runner
registration,
Workforce
or
creation
workflows,
and
so
we
have
a
bunch
of
work
here.
You
can
see
that's
planned
in
terms
of
some
back-end
world,
that's
required
both
in
the
rail
side
and
there's
also
some
work
and
a
runner
core
code
base
itself.
B
That's
enabling
that
new
Runner
creation
workflow
that
Gina
just
talked
about
so
there's
a
bunch
of
efforts
there
on
that.
So
it's
not
necessarily
the
consumable
feature
that
you'll
see
in
59
will
be
the
thing
that
Gina
was
pointing
out
earlier,
which
is
hey.
You
might
real
if
you're
on
the
admin
level
you'll
be
able
to
start
creating
one
as
and
testing
out
the
new
workflows.
B
This
list
will
change
because
we'll
it's
probably
at
this
point
a
little
bit
over
in
terms
of
our
capacity
but
again
we'll
we're
continuing
to
focus
on
burning
down
our
Legacy
P2
bugs
and
we're
trying
to
get
to
a
state
where
we
are
achieving
our
civil
server
objectives
for
new,
specifically
S2
buggers.
They
come
in
and
so
on.
So
this
is
kind
of
what
you're
seeing
here
is
that
that
continued
focus
on
bug
burn
down
again,
once
we
get
into
actual
iteration
execution
next
couple
of
days,
this
will
be
fine.
B
I
will
be
pairing
it
down
to
the
actual
bugs
that
we'll
be
able
to
fill
into
the
release
Milestone
based
on
our
capacity
from
a
new
features
perspective
the
there
is
actually
one
specific
and
maybe
significant
new
feature
that
I
want
to
call
out
in
the
runical
code
base.
Then
I'm
really
hopeful.
We
can
get
shipped
in
59
and
this
is
I'll
click
on
it
here.
It's
this
idea
in
terms
of
using
kubernetes
Secrets.
B
Let
me
open
this
up
instead
of
config
map
for
storing
variables,
so
right
now,
in
the
run,
if
you're
using
the
gitlab
runner
with
the
queue,
this
executor,
which
basically
means
you're
able
to
run
your
gitlab
CI
jobs
on
a
kubernetes
cluster
and
what
happens
in
that
scenario,
is
that
each
job
runs
in
its
own
local
pod.
So
it's
really
a
very
super
efficient
way
to
run
your
gitlab
CI
jobs
as
gear,
especially
if
those
jobs
could
want
to
continue
as
a
continuous
environments
order.
B
The
next
operating
system,
the
tldr
is
today
all
of
the
variables
that
the
task
from
gitlab
CI
into
the
Pod
definition.
Those
variables
are
stored
in
kubernetes
config
maps
and
I'm.
Not
going
to
go
into
a
little
bit
of
detail
into
what
the
fixed
maps
are,
this
tldr
on
the
short
of
it
is
that
we
want
to
move
to
using
the
kubernetes
secret
subjects
for
storing
those
variables,
and
that
would
make
things
a
lot
more
secure
in
terms
of
some
of
the
variables
that
we
pass
in
from
gitlab
CI
into
the
Pod
definition.
B
The
thing
to
call
out
here
is
that
those
variables
that
you
see
in
the
Pod
definition
they're
only
visible
to
folks
that
or
users
that
have
actual
access
to
the
kubernetes
cluster.
So
again,
this
is
one
interesting
new
feature:
we're
working
on
to
make
things
a
bit
more
secure,
but
again,
if
you're
using
kubernetes
today
to
run
your
jobs,
only
those
admins
that
have
access
to
your
cluster.
Only
those
folks
that
have
the
permissions
to
run
Cube
CTL
commands
on
your
cluster
can
actually
see
the
information
and
the
active
running
run
a
kubernetes
worker
pod.
B
So
I'm
super
hopeful
that
we
can
get
this
feature
shipped.
It
will
make
our
kubernetes
solution
a
lot
more
secure,
a
lot
more
and
kind
of
move
things
into
the
right
path,
but
in
terms
of
what
we
want
to
do
in
terms
of
moving
away
some
structures
from
config
Maps,
the
that's
really
and
the
oh,
that's
one
more
about
the
thing.
I
want
to
call
it
as
well
in
terms
of
run.
B
If
that
is
your
provider
of
choice
and
then
the
bowling
59
will
be,
will
us
we'll
be
looking
to
potentially
extend
or
to
release
the
out
for
the
alpha
for
gcp
or
Google
Cloud?
So
there's
a
whole
lot
of
work
planned
in
the
next
in
59
1510
1511
around
us
releasing
iterations
of
the
auto
scaling
solution
for
various
public
Cloud
providers,
so
we're
doing
alphas
and
AWS
10
on
gcp,
then
we're
going
to
Beta
and
we're
doing
it
on
an
Azure
and
so
on.
So
keep
looking
out
for
that.
So
that's
it.