►
From YouTube: GitLab 15.7: Kickoff - Verify:Runner
A
Hey
everyone
Gina
Doyle
and
Darren
Eastman
here,
part
of
the
runner
group
and
today
we're
going
to
go
over
the
15-7
Milestone
planning
issue
that
we
have
I'll
start
off
with
going
over
the
runner
Fleet
category
group
that
we
have
and
so
I'll
share
my
screen
and
just
as
a
reminder,
I'll
just
show
the
category
Direction
page
here,
Runner
Fleet
is
focused
on
providing
an
area
where
you
can
manage
all
of
your
build
agents
in
an
and
environments
at
Enterprise
scale.
A
So
we
want
to
make
this
as
easy
as
possible
for
you
and
then,
as
part
of
our
vision,
we're
going
to
be
delivering
more
of
a
centralized
view
with
all
these
different
management
capabilities
and
Predictive
Analytics
in
the
future.
And
today
what
we
are
taking
on
for
development
within
Runner
Fleet
and
one
of
them
is
around
paginating
the
shared
runners
in
the
project,
CI
CD
settings
area.
You
can
have
tons
of
shared
Runners,
especially
when
you're
on
gitlab.com
WE
Supply
lots
of
shared
Runners.
A
So
if
we
are
able
to
paginate
that
it
will
give
the
page
more
improved
performance
and
then
also
just
allow
you
to
find
them
quicker,
another
thing
that
we're
going
to
be
taking
on
is
indicating
if
a
runner
is
busy
or
not-
and
this
is
something
that
we're
really
excited
to
do
today.
A
There's
no
easy
way
to
tell
if
a
runner
is
currently
running
a
job,
so
we'll
be
adding
basically
a
runner
badge
that
allows
you
to
see
if
it's
running
a
job
or
if
it's
idle
at
the
moment
and
then
for
ux
for
15
7
I'll
be
working
on
providing
an
estimated
wait
time,
for
instance
Runners.
This
is
our
MVC
for
more
of
the
runner
Fleet
Q
monitoring
area.
A
We're
really
excited
for
this,
because
we
know
that
a
lot
of
people
need
more
insight
into
how
long
jobs
will
take
to
be
picked
up
and
how
busy
your
Runners
are
over
time.
And
we
think
that
by
providing
this
first
feature,
we
can
continue
to
build
on
it
and
provide
you
more
metrics
around
your
estimated
waiting
times
for
your
runners
and
I'll,
pass
it
to
Darren
for
Runner
core
and
Seth.
B
Hey
Junior
thanks
a
bunch,
hey
everyone.
So
let
me
share
my
screen
really
fast
and
I'll
talk
about
a
few
key
things
that
are
important
to
note
for
Runner
core
piece
of
the
runner
group,
I'm
specific
to
Rona
SAS.
We
don't
have
anything
planned
to
ship
in
15-79.
I.
Don't
have
the
the
planning
issue
in
front
of
me
right
now,
but
we
are
going
to
continue
to
work
on
moving
the
more
forward
with
getting
set
up
for
moving
our
Mac
OS
Runners
to
limited
availability.
B
So
that's
a
key
piece
of
all
that
we're
working
on
and
in
parallel,
we're
also
doing
a
bunch
of
work.
That's
going
to
eventually
cross
back
over
to
the
runner
quad
team,
we're
doing
a
bunch
of
work
on
the
next
Runner
Auto
scaling
architecture.
So
things
like
some
of
the
alpha
releases
for
what
we're
calling
the
the
fleeting
plug-in.
That's
part
of
our
Task
Killer
technology.
B
You'll
see
some
of
that
coming
out
in
15
7.,
but
the
goal
for
the
main
goal
that
we're
working
on
for
Verona
SAS
team
is
really
on
Mac
OS
for
the
back
half
of
Q4
and
for
running
core
57.
Specifically,
just
like
15
said
since
55
in
the
previous
releases
first
order,
property
for
us
is
on
any
like
super
important,
high
priority
issues.
B
Typically,
security
vulnerabilities
and
those
types
of
things-
I
don't
have
anything
quite
on
a
ducky
yet
pulled
out
in
157,
so
that
that's
that
we're
gonna
have
some
passive
for
other
things
in
157.
B
So
beyond
that,
the
next
level
of
work
that
we
always
want
to
focus
on
is
on
our
aged
bug
background,
and
so
you
can
see
here
under
run
a
core
category.
We
have
a
number
of
bugs
that
we
would
like
to
get
to
in
15
7.,
and
so
that's
again,
we'll
continue
to
invest
in
burning
down
the
age.
Buff
backlog
I'm,
the
one
copy
that
I
want
to
call
out
is
that
we
also
had
some
bugs
planned
in
1506.
We
did
resolve
a
few
bucks
and
156.
B
There
are
set
a
few
bugs
open,
so
those
will
roll
over
but
must
be,
which
we
lock
and
the
56
release,
we'll
see
which
blocks
from
156
that
did
not
get
fixed
would
have
to
roll
over
15.7.
So
so
this
plan
will
adjust
a
tad
bit,
but
the
the
story-
The
takeaway,
is
first
order
of
business
is
we'll
continue
to
invest
in
reducing
our
backlog
of
aged
severity
to
bugs
and
they're
going
to
call
category
from
a
new
features
perspective,
and
actually
I
should
quote
us
out
here.
B
There's
a
new
bug
here
under
on
a
call
with
this
label
the
priority
one
and
it's
variable.
Expansion
with
default
paths
no
longer
works
for
other
packs,
and
this
came
in
some
systems
by
15.5
and
the
reason
this
bug
is
there
is
that
n155
we
had
to
release
a
feature
to
take
care
of
of
a
security
issue,
and
there
are
a
couple
of
edge
cases
related
to
artifact
handling
and
specifically
variables,
and
patents
and
I've
got
handling
that
was
affected
as
a
result
of
that
feature
set,
and
so
that's
the
bug.
B
In
order
to
resolve
that
Bob,
we
are
proposing
a
new
feature
in
one
of
reporting:
it,
the
passive
values
between
job
steps
and
what
what
this
will
enable
users
to
do
is
to
be
able
to
set
a
script
level
environment
variable
that
can
then
be
passed.
Other
stages
of
the
pipeline,
and
so
we
believe
with
this
capability,
will
resolve
most
of
the
edge
cases
or
most
of
the
use
cases.
I
should
say
to
me
to
be
more
accurate
that
customers
are
reporting
on
that
other
book.
B
So
the
past
values
between
job
search
is
a
brand
new
feature
in
gitlab
runner
call
and
that
we're
hoping
to
ship
in
157,
which
is
in
a
response
to
us
having
to
fix
some
issues
that
came
out
that
are
that
are
categorized
here
on
the
display
of
the
view
of
the
expansion
with
default
in
the
local
workspace.
B
The
other
important
feature
that
we
have
picked
up
in
157,
if
you
want
to
call,
is
related
to
variable
handling
from
hashicor
Vault,
and
this
is
the
ability
for
us
to
correctly
mask
any
secrets,
any
variables
that
are
stored
in
hashico
Fault
and
so
there's
some
additional
work
that
we
did.
There's
some
pretty
work
that
we
did
on
this
appear
releases
back
in
runaway.
B
We
added
support
for
continuing
masking
our
variables
over
four
kilo
over
4K
IB
in
size,
and
this
is
the
last
piece
of
work
to
ensure
that
any
variables
stored
in
hashikov
are
mask
fully
so
that
they're
not
exposed
in
the
job
valves.
So
the
goal
would
be
in
15.7
to
add
a
remaining
piece
of
work
in
runner
that
takes
care
of
masking
those
variables.
So
from
a
new
feature
perspective.
Those
are
the
two
things
that
are
super
important
that
we'll
need
to
get
done
in
15
7..
B
One
other
feature
I
want
to
call
out
to
that's.
That's
super
interesting
as
well
is
in
the
in
the
Cuban
is
running
an
equivalency
executive
Corona.
This
concept
that
was
driven
by
initially
by
Community
Mr,
the
ability
to
override
or
overwrite
the
notes,
because
selector
configuration
for
the
gets
that
run
on
kubernetes.
B
Today,
as
a
user
of
the
kubernetes
executor,
you
can
set
the
node
selectors,
but
you
have
to
set
that
in
your
config.yaml
and
you
configure
Tamil
file
and
you
can't
necessarily
overwrite
overwrite
or
overwrite
that
in
your
pipeline
file
and
so
what
we
want
to
be
able
to
do,
which
will
unlock
a
lot
of
interesting
use.
Cases
for
customers
on
platforms
like
Google
gke
autopilot
is
the
ability
to
overwrite
the
node
selector
within
the
pipeline,
which
gives
you
a
lot
of
flexibility
in
terms
of
what
you
can
do
with
hosting
Runners
on
K8.
B
So
you
now
enabling
the
configuration
setting
of
what
type
of
compute
class
your
pod
or
your
Runner
pod,
actually
then
create
on
Google
just
by
the
ability
to
Define
that
in
the
pipeline
file.
So
this
is
a
really
super
interesting
feature
that
I'm
hoping
hoping
that
we
can
get
done
in
157.
It's
a
really
interesting
piece
of
capability
that
unlocks
a
number
of
great
bits
of
potential
forerunners
on
k8s.
B
So
that's
it
in
terms
of
what
we
have
planned
for
round.
Four,
any
padding
would
Sheena
from
your
side.