►
From YouTube: UX Showcase visibility into runner fleets
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
I
I'm
gonna,
pretty
much
fly
through
the
presentation,
just
because
I
would
love
to
spend
most
of
the
time
doing
a
more
discussion
with
the
team
who
offers
on
the
call
okay,
so
a
quick,
runner's
refresher
just
because
we
don't
always
have
to
deal
with
Runners
every
day,
so
Runners
power,
CI
CD,
because
they
are
the
machines
that
actually
run
the
jobs.
A
A
common
example
that
a
lot
of
us
in
the
ux
department
will
go
through
is
when
we're
creating
an
MR
to
update
a
handbook
page,
for
example,
when
you
create
that
Mr
you'll
see
on
the
page
that
a
pipeline
automatically
starts
running
because
that's
how
we've
set
it
up
for
that
project
and
it
usually
includes
stages
which
are
those
larger
icons
that
look
like
build
and
deploy
or
test.
You
might
see,
stages
name
something
else,
and
each
of
those
stages
contain
one
or
many
jobs.
A
Typically,
if
we're
following
some
good
naming
structures,
the
stage
names
will
represent
the
jobs
that
are
in
that
stage.
For
example,
the
test
stage
would
contain
jobs
that
test
the
code,
which
might
also
be
named
in
some
variation
of
tests,
and
then
each
one
of
those
jobs
is
what
is
picked
up
by
a
shared
runner
in
our
case,
because
we're
using
gitlab.com
and
each
one
of
those
shared
Runners
has
a
tag.
So
when
you
I'm
gonna
just
bring
this
up,
because
this
is
my
example
page
that
we
can
use.
A
A
I
can
see
the
runner
that
ran
this
and
then
I
can
also
see
the
tags
that
were
used.
So,
in
order
for
this
Runner
to
pick
up
this
job,
it
has
to
have
the
same
tag.
That's
how
Runners
have
that's
how
they
just
pick
up
jobs.
They
have
to
have
the
same
tag
in
order
to
do
that,
all
right,
so
I'm
going
to
go
back
here,
and
so
this
is
like
best
case
scenario.
Everything
goes
well,
you
see
the
runner
picks
it
up,
but
what
happens
if
there's
an
issue
with
the
runner?
A
You
can
use
your
little
raised
hand
in
here
if
you've
ever
sat
and
wondered
why
it's
taken
so
long
for
a
job
to
move
from
panning
state
or
maybe
you're
sitting
there
waiting
for
a
job
to
finish
running,
and
that
might
happen
when
you're,
creating
an
MR
or
reviewing
an
MR
or
even
just
running
a
pipeline.
I've
I
know
I've
been
in
that
situation
many
of
times
and
have
been
wondering
what's
happening.
A
So
at
this
point
your
workflow
is
completely
blocked.
You
can't
debug
why
the
job
is
pending.
You
don't
have
access
to
see
shared
Runner
details
because
you're,
not
an
admin.
Only
gitlab
admins
can
get
details
into
those
shared
Runners,
and
this
is
something
that
our
actual
company
does.
We
have
a
team
that
manages
all
of
our
shared
Runners
that
we
supply
for
anyone
using
gitlab.com
and
they're,
the
only
ones
who
can
access
those
Runners.
So
as
a
developer.
In
our
case,
what
do
we
do?
A
What
we've
been
seeing
and
hearing
is
that
developers
will
reach
out
to
admins
through
slack
or
whatever
other
communication
portal
or
program
they're
using
and
basically
say
hey
this
job
is
stuck
in
pending.
Is
there
some
way
that
you
can
bump
it
up
or
is
there
something
wrong
with
a
runner,
and
so
admins
in
this
case
are
very
reactive.
A
They
often
check
the
UI
quickly
for
our
Runners
page,
just
to
get
a
sense
of
Runner
status,
seeing
making
sure
everything
is
online,
but
then
they
often
go
into
Runner
logs
locally,
something
that
they
can
get
up
locally
or,
if
they're
hosting
their
Runners
through
a
cloud
platform
which
a
lot
of
our
users
do.
They'll
look
at
the
runner
logs
there
to
see
more
and
see
what's
happening
with
them.
A
Okay,
so
now
the
question
is:
how
do
we
switch
admins
from
reactive
mode
to
proactive
mode
when
they're
managing
their
fleets
I
use?
The
word
fleets
here,
because
we
often
refer
to
a
number
of
Runners,
that
the
user
is
managing
as
a
fleet.
So
you'll
often
hear
me
say
like
Fleet
of
runners
or
Runner
Fleet.
A
It's
something
that
you
can
configure
based
on
a
single
Runners
configuration.
So
we
would
like
to
get
more
data,
but
at
the
moment
we
only
have
so
much
so
this
is
going
to
be
like
our
MVC
and
then.
Lastly,
we're
going
to
share
mean
wait
times
which
will
help
us,
like
specifically
in
these
situations,
who
are
waiting
for
a
job
to
get
picked
up.
How
long
does
it
take
for
runners
to
pick
up
a
job,
and
we
learned
these
key
data
points
from
running
solution?
A
A
It
might
not
look
like
this
just
yet,
but
we're
getting
there
it's
behind
a
feature
flag
at
the
moment,
but
as
you
can
see,
we
have
something
specifically
about
Fleet
Health,
we're
presenting
the
runner
failures
which,
for
our
case,
if
we
go
back
to
the
scenario
I
put
put
us
through
if
a
runner
is
failing
at
that
moment,
the
admin
needs
to
know.
A
So
this
will
give
them
immediate
visibility
into
that,
and
then
we
have
active
Runners
over
here,
which
are
those
Runners
that
are
running
a
specific
number
of
jobs
at
one
time,
and
then
you
actually
get
a
list
of
the
jobs
that
they're
running.
If
you
click
on
those
two
which
is
really
nice
for
them
to
get
visibility
into
that,
and
then
this
is
the
the
thing
that
brings
me
the
most
Joy
on
this
dashboard
is
this
graph
of
wait
time
to
pick
up
a
job.
A
The
reason
why
is
because
RCI
builds
table
in
our
database
at
gitlab
is
the
largest
table
and
actually
being
able
to
store
historical
or
even
current
job.
Metrics
is
seemingly
impossible
because
we
run
so
many
jobs
per
hour.
We
at
gitlab
we
run
over
a
hundred
thousand
jobs
per
hour
per
hour,
so
storing
all
that
data
in
a
performant
way
is
pretty
difficult,
but
the
key
for
us
to
be
able
to
do
this
is
that
we
use
clickhouse.
A
This
is
something
I'm
gonna
bring
up
at
the
end.
If
nobody
has
questions
to
discuss
more
about,
because
this
is
the
only
thing
that
like
enabled
us
to
be
able
to
create
a
feature
like
this
and
it's
great,
so
our
next
steps,
just
as
as
our
team
moves
on
with
this
dashboard,
we're
going
to
run
an
early
adopters
program
to
get
feedback
on
the
feature
before
releasing
it
fully.
The
reason
why
we
need
to
do
this
is
in
order
for
self-managed
users
to
use
this
dashboard.
A
They
have
to
obviously
enable
the
feature
flag
and
then
they
also
have
to
do
specific
things
to
get
clickhouse
to
work,
so
we're
gonna
run
them
through
a
whole
setup
document
for
them
to
be
able
to
do
that
and
then
we'll
continue
to
get
feedback
from
them.
And
then
we
have
a
lot
of
more
iterations
on
the
dashboard
to
get
to
that
final
Vision
State,
as
well
as
new
features
to
add
in
the
future
and
I've
linked
both
those
epics
in
our
document
and
then.
A
Lastly,
obviously
we
want
to
release
fully
and
we
especially
want
to
add
this
to
groups
on
our
hitlab.com
on
the
SAS
program,
so
that
is
kind
of
the
end
of
that.
I
wanted
to
hop
over
just
to
see
if
anyone
has
questions
before
I
bring
up
that
larger
discussion
item.
B
I
have
a
question:
the
yeah,
the
design
you
showed,
looks
pretty
robust.
What's
your
vision
or
end
game
like
where
do
you
think
this
will
end
up.
A
Yeah
so
I
would
say
this
was
our
initial
vision,
but
obviously
we
can't
add.
We
can't
continue
to
add
as
many
features
as
we
want
to
this
dashboard
like
that's,
not
going
to
be
feasible
or
scalable
for
us
so
we'd
like
to
without
adding
things
to
the
navigation
we
actually
are
going
to
be
able
to
link
I
think
we
ended
up
using
like
contextual
links
as
the
name
for
this,
but
we
want
to
link
to
full
reports
of
of
these
things.
A
For
example,
viewing
all
failed
Runners
will
show
a
full
list
of
these,
so
that
you're
not
just
seeing
a
snapshot
of
them
and
then,
as
well
as
like
wait
time
to
pick
up
a
job,
it
will
be
a
full
report,
so
that
is
more
of
our.
Our
end
game
is
to
be
able
to
link
out
to
view
more
details
about
these
things.
C
A
So
we
are
just
showing
the
top
five
active
Runners,
because,
if
a
like,
so
if
we're
looking
at
this
first
runner,
of
course,
I
named
them
all
501.
But
let's
pretend
that
they
had
a
distinct
name
if
they're,
if
they
are
configured
to
run
100
jobs.
At
the
same
time,
and
you
see
consistently
that
they're
running
90
jobs,
then
there
might
be
a
a
chance
for
the
admin
to
be
able
to
lower
the
number
of
concurrent
jobs
so
that
they're
not
paying
for
as
much
machine
size
as
they
are
currently
so
like.
A
If
you
wanted
to
run
100
jobs
at
a
moment
they
would
have
to,
they
would
have
to
be
a
certain
machine,
size
and
you'd,
be
paying
more
so
in
that
by
ranking
these
we're
trying
to
give
them
a
little
bit
more
insight
into
which
Runners
are
running
the
most
jobs
at
once,
because
those
are
the
ones
that
you
can
see
that
you
might
be
able
to
tweak
to
to
run
pipelines
more
efficiently
and
then
to
like
not
pay
for
as
much.
If
that
makes
sense,.
C
B
What's
the
communication
mechanism
so
right
now
at
users
or
developers
after
paying
admin
to
say,
hey,
what's
the
deal,
we
get
it?
How
did
you
get
around
that.
A
A
Yes,
we'll
give
admins
more
insight
before
problems
happen
by
showing
them
these
dashboards,
because
we
can
give
them
some
historical
data,
but
I
think
what
would
stop.
This
is
for
developers
to
be
to
be
able
to
self-serve
themselves,
and
we
haven't
made
progress
to
give
developers
more
information.
Yet,
for
example,
we
could
give
developers
a
mean,
wait
time
for
their
jobs
to
be
picked
up
in
pending
state,
but
our
our
priority
right
now
is
giving
admins
that.
C
Cool,
oh,
go
ahead!
Yeah!
Sorry,
did
you
also
hear
you
say
something
about
like
there
could
be
more
items
on
that
dashboard
like
there
could
be
more
data,
that's
configured
in
various
ways,
because
there
might
be
an
opportunity
for
us
to
collaborate,
it's
currently
in
the
backlog,
but
Andy.
Actually,
when
he
was
the
designer
on
thread.
Insights
came
up
with
this.
C
What
I
think
it's
a
genius
idea
where
there's
so
much,
there's
so
many
variables
when
it
comes
to
vulnerabilities
like
how,
like
the
number
of
vulnerabilities
that
came
in
over
time
or
the
level
of
severity,
how
many
criticals
or
where
are
they
coming
from
if
their
source
code,
like
SAS
vulnerabilities
like
where
are
they
being
detected?
There's
just
there's
a
lot
of
ways.
C
You
can
break
down
that
data
and
so,
rather
than
just
reactively
design
a
different
widget,
he
came
up
and
he
came
up
with
the
idea
of
just
like
what,
if
we
built
out
a
configurable
dashboard
where
they
could,
just
like
you
know,
let's
say
a
drawer
or
something
opens
up,
and
it's
like
what
information
do
you
want
in
this
widget
and
so
they're
basically
designing
their
own
widgets
and
that's
a
lot
more
scalable.
C
So
I
don't
know
if
that
would
make
sense
for
for
runners
as
well,
but
if
so,
we
could
collaborate
on
it.
Although
that's
probably
20
25
thing,
yeah,
2024,
I,
don't
know
what
year
it
is
like.
Next
year
at
least.
A
A
I
think
where
we're
at
right
now
is
just
giving
them
a
step
into
like
getting
this
visibility
first
and
then
I
think
it
would
be
great
to
be
to
give
them
that
flexibility
to
create
their
own
dashboard,
like
you're,
saying
because
it
in
a
similar
way,
Runners
you
can
even
Runners
relate
to
jobs,
so
they
might
end
up
wanting
to
see
job
data
on
that
dashboard
and
I
think
we'll
get
to
know
more
as
we
get
feedback
on
that
feature.
A
Yeah
I
have
a
lot
more
to
say
about
that.
So
we
can
talk
async
because
there's
a
lot
more
research
Erica
actually
just
did
that
relates
to
that
as
well.
Oh.
A
Yeah
I
think
I'm
at
time.
I
had
a
question
that
I
wanted
to
get
the
team's
opinion
on
as
well
just
based
on
what
you've
experienced
in
similar
data
sets.
If
you're
dealing
with
large
data
sets,
so
maybe
we
could
fill
that
out
async.
If
you
have
time.