►
From YouTube: GitLab Kick-off 13.8 - Verify:Runner
Description
GitLab Runner release 13.8 iteration kickoff video.
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27251
https://about.gitlab.com/direction/verify/runner/
A
Hey
everyone
happy
holidays,
darren,
eastman
here,
product
manager
for
gitlab
runner,
hey
so
today,
we'll
cover,
as
always,
the
iteration
plan
for
forget,
labor
and
specifically
the
1398
iteration
plan,
given,
of
course
that
is
december.
It's
the
holiday
season
for
a
lot
of
folks
across
the
world.
We
have
a
few
of
our
team
members
that
are
taking
some
extended
time
off
and
getting
some
values
of
wrestling
relaxation,
and
this
has
been
a
very
long
and
trying
yeah
for
a
number
of
us,
and
so
with
that
said,
we
have
some
reasonable
goals
for
308.
A
As
always,
we've
got
the
roman
team
iteration
plan,
which
you
can
go
and
have
a
look
at
in
github
itself
and
then
read
a
quick
aside
since
this
is
our
last
kpop
video
for
this
calendar
yeah.
I
will
also
be
following
I'll,
also
be
following
up
with
a
more
extensive
video
that
talks
about
the
broader
gitlab
runner
vision
strategy
and
how
that
fits
into
the
overall
gitlab
strategy
in
terms
of
having
been
that
single
devops
platform.
A
So
we'll
look
forward
to
that,
we'll
cover,
hopefully
kind
of
how
we
see
things
evolving
with
github
and
over
the
next
few
years.
Obviously
things
will
change,
but
we
at
least
kind
of
paint,
a
picture
in
terms
of
how
we
think
things
will
well
so
look
forward
to
that
that
forthcoming
video
so
jumping
into
third
and
update
for
those
who
have
kind
of
been
following
along
the
one
change
that
we
made
in
our
iteration
plan.
A
The
first
feature:
we're
now
calling
allow
user
to
specify
multiple
policy
for
the
doctor
executor.
We
talked
about
it
in
13.7.
We
had
a
different
name
back
then
for
it
in
thirteen
at
seven
and
then
back
in
the
problem.
This
particular
feature
was
meant
to
solve,
was
in
certain
cases,
if
the
for
some
reason
and
while
you're,
while
the
the
gitlab
runner,
whether
it's
on
the
docker
executor
on
the
community
executive,
it's
trying
to
retrieve
the
container
image
from
a
target
container
registry.
A
Those
network
failures,
more
availability,
failures
of
the
target
container
registry,
so
one
of
our
engineers
who's
working
on
this
steve
as
a
paradigm
actually,
as
he
got
into
this
kind
of,
came
up
with
a
different
concept
and
we'll
talk
about
what
that
new
concept
is
here
really
quickly
to
help
help
us
kind
of
understand
what
that
looks
like.
Let
me
just
pop
over
here
and
just
quickly,
zoom
in-
and
I
put
this
together
because
just
in
reading
some
of
the
community
discussions
on
related
merge
requests
that
we
had
around
this
particular
space.
A
So
I
felt
that
to
give
folks
a
bit
more
context
in
terms
of
what
this
new
feature
is:
let's
go
ahead
and
put
together
something
that
supposed
to
quickly
visualize
the
current
state
and
then
what
the
new
capability
will
look
like
it's
just
really
fast
in
the
top
quality
of
the
screen.
Here.
What
we're
describing
what
I'm
describing
are
the
current
pole,
policies
that
are
available
in
the
git
lab
runs
today,
both
the
docker
executor,
as
well
as
the
cuban
executor
and
again
this
this
match.
A
What
you
see
upstream
in
kubernetes,
so
you
have
the-
if
not
present
the
always
and
the
never
pull
policies
so
really
quickly.
If
not
present,
the
logic
basic
is
pretty
straightforward
right.
If
the
container
image
is
available
locally
during
the
execution
of
a
pipeline
job,
then
we'll
use
a
locally
available
container
image.
If
it's
not
available
locally,
then
connect
to
the
container
registry
and
pull
the
image
from
the
container
registry
of
choice.
That's
the
type
of
container
you
just
set
always
is
pretty
straightforward.
A
A
The
os
policy,
which
is
this
one
if
the
connection
to
the
container
registry
is
successful,
yes,
then
go
ahead
and
pull
the
image
from
the
container
registry.
Here
is
the
fallback
mechanism.
The
fallback
mechanism
is
in
this
logic.
If
the
connection
is
fair,
which
is
the
no
in
the
logic
flow.
If
the
connection
failures
equals
to
no
then
use
the,
if
not
present,
for
policy
so
which
then
basically
says
how
I
can
go
ahead
and
pull
this
image
locally.
A
The
other
thing
that
we're
doing
in
thickness
8
is
that
we
are
wrapping
up
some
work
related
to
the
variable
inside
of
the
variable
feature,
which
is
this
one
we're
looking
at
it
here
on
our
fit
and
integration
plan.
The
specific
subset
of
the
work
that
we
started
in
397,
that's
pretty
close
to
getting
done
actually,
which
is
very
exciting
to
see,
but
we'll
have
to
wrap
up
some
of
your.
The
reviews
for
the
openmrs
infinitely
before
we
can
we
can
merge
that
into
the
code
base.
A
Is
this
logic
around
introducing
a
topological
sort
so
anyway,
the
the
main
issue
that
we're
trying
to
deliver
deliver?
Is
this
used
variable
inside
other
variable
issue
and
what's
interesting
about
this?
Is
as
we've
gotten
into
this
from
a
runner
engineering
perspective,
and
we
have
realized
that
now
that,
with
this
specific
feature,
most
of
the
work
is
actually
going
to
be
happening
outside
of
the
runner
or
all
of
the
work
actually
is
going
to
be
happening
outside
and
really
in
our
quote-unquote
rails,
app
in
the
gitlab
app
itself.
A
So
we're
pretty
close
in
terms
of
fitting
and
the
focus
into
398
will
be
to
wrap
up
the
the
variable
topological
sort
feature.
So
what
that
gets
us
is.
It
gets
us
most
of
the
logic
that
allows
us
to
to
to
eventually
ship
this
feature
where
you
will
be
able
to
define
a
variable
in
a
gitlab
diamond
file
and
then
use
that
variable
definition
later
all
within
the
single
gamma
found.
The
other
pieces
that
are
missing,
however,
is
when
we're
done
entering
the
day
with
the
topological
sword.
A
I
should
disclose
that
with
a
topological
sword
capability
that
would
be
that
will
be
behind
a
feature
flag,
we'll
need
to
come
back
in
and
make
some
ui
changes
and
say
the
13.9
iteration,
so
that
you
can
have
a
toggle
switch
in
the
ui,
so
that'll
be
the
other
additional
work
we
have
before.
We
can
have
a
fully
functional
feature:
that's
easy
to
ship.
So,
oh
one
of
our
one
engineers
is
looking
to
wrap
that
up
in
398.
A
A
A
A
This
particular
testing
activity
is
related
to
us,
adding
we
are
featured
here,
the
long-term
sort
of
long-term
next
couple
of
releases,
or
if
we
get
to
it,
it's
adding
support
for
apartment,
2.1
plus.
So,
let's
just
say
two
or
two
at
this
point
to
the
gitlab
runner.
There's
a
lot
of
there's
been
a
lot
of
communications
from
manhattan
around
the
fact
that
the
duck
container
engine
is
no
longer
is
not
an
open
shift,
all
in
red
hat
enterprise.
A
Next,
eight,
the
the
red
hat
container,
runtime
solutions-
if
you
will
our
pubmed
builder,
scopio
and
1c,
and
so
with
parkman
2.0,
we
believe
and
then
the
extension
and
the
use
of
an
a
of
an
api,
that's
sort
of
compatible.
It
seems
very
likely
that
it's
it's
more,
it's
easier
for
us
to
add
support
for
apartment
2.1
to
get
lab
running
in
terms
of
the
actual
testing
activity.
A
Since
we
created
this
issue
about
a
week
ago,
there's
been
a
number
of
community
members
and
I
think
some
folks
from
the
the
red
hat
community
as
well.
That's
already
actually
gotten
it
and
jumped
on
this
and
actually
started
testing.
So
our
work
in
in
3.8
will
just
probably
hopefully
be
a
final
bit
of
validation,
making
sure
that
there
are
no
edge
cases
that
we
have
missed
and
so
that
again,
this
will
help
us
inform.
A
The
focus
in
38.8
continues
to
be
the
work
on
the
auto
scaler
to
support
the
beta
rollouts
of
the
mac,
os
bell
cloud
or
mac
os
runners
on
gitlab.com,
again,
just
to
recap
we're
currently
in
a
closed
beta
for
the
mac
os
bell
cloud.
We
have
a
number
of
folks
on
there.
The
auto
scale
is
what
will
allow
us
to
auto
scale
that
environment
that
we're
using
to
to
handle?
A
You
know
ci
jobs
at
scale,
so
the
auto
scaling
work
will
continue
in
third
in
the
day
and
then
around
our
sort
of
our
broad
run,
enterprise
management,
sort
of
get
that
all
things
related
to
the
runner
in
the
gitlab
ui
bucket.
Nothing
planner
shipping
308
as
we
and,
as
I
mentioned,
we'll
be
creating
another
venue
around
the
long
term
version
and
strategy.
A
So
we'll
talk
a
bit
more
detail
there
about
some
of
the
things
that
we've
heard
from
customers
that
are
informing
the
areas
that
we
want
to
prioritize
in
improving
the
runner
user
experience
in
the
actual
github
ui
and
then
in
terms
of
capabilities
that
are
interesting
and
helpful
and
will
provide
value
for
sort
of
enterprise,
management
of
romance
and
skill.
So
that's
it
for
thirteen
at
eight
plan.