►
Description
Gina Doyle (Sr. Product Designer: Runner Fleet) summarizes the proposal for runner groups.
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/388854
A
Hey
team,
Miguel
and
I
had
met
earlier
today
and
talked
about
this
issue
based
on
some
feedback
that
I
got
from
the
team,
which
brought
up
some
really
great
concerns
about
performance
of
the
page
and
over
complicating
the
runner's
page.
A
bit
I
also
met
with
hayana
who's,
my
design
manager
to
review
like
where
we
should
go
next
for
the
MVC.
A
So
my
my
proposal
for
the
MVC
now
is
to
really
simplify
things
so
that
again
we're
not
over
complicating
and
then
we
can
use
instrumentation
to
learn
a
little
bit
more
about
what.
If
we
need
to
make
iterations
in
the
future,
how
we
should
do
that
and
then
we
can
potentially
bring
in
more
data
as
I
kind
of
was
trying
to
support
in
the
beginning,
but
now
I'm
I'm
no
longer
supporting
that
okay.
A
So
the
proposal
now
is
to
remove
the
expandable
rows
so,
but
I'd
still
like
to
group
the
data
about
the
runners
that
are
in
a
group,
so
we
can
summarize
them.
I
know
that
right
now
we
don't
have
summaries
of
the
status
is
I
believe
or
it's
going
to
be
really
complicated.
So
we
can
talk
about
how
we
present
the
statuses
in
the
beginning
for
the
MVC,
maybe
like
we
said
before.
Maybe
we
just
take
whatever
one
has
contacted
gitlab
most
recently,
I
think
that
that
again
can
cause
confusion.
A
The
other
thing
that
I've
changed
is
I've
moved
the
number
of
Runners
that
are
in
the
group
to
a
badge
and
then,
when
you
hover
over
it,
it
says
two
runners
in
this
group
think
that
makes
it
a
little
bit
more
obvious
and
distinct.
A
This
makes
it
more
distinct
from
the
other
ones
and
and
then
we're
still
summarizing
the
data
here.
Like,
however,
many
upgrades
are
available
of
the
whole
group,
that's
in
there
and
then
we're
only
presenting
last
Runner
created
what
whatever
day
I
go.
A
So
then
the
numbers
up
here
I
also
wanted
to
bring
up
the
total
numbers.
Those
include
the
what
we're
calling
Runner
managers
that
are
in
those
groups,
so
I
have
11
Runners
right
now,
even
though
I
don't
have
11
items
in
this
table,
I
have
11.
If
we
count
up
all
the
totals
plus
the
individual
Runners
that
are
in
here,
I
think
that
that
makes
the
most
sense,
because
those
Runners
are
still
alive
and
potentially
running
jobs.
So
I
do
still
think
that
we
should
add
them
up
into
the
totals.
A
A
So
if
we
have
further
documentation
about
why
we
did
this
and
stuff
that's
what
I
would
hope
to
to
link
out
to.
But
then,
if
you
show
the
details
of
the
runners
in
that
group,
you'll
get
a
breakdown
of
their
statuses,
will
include
the
system,
ID
version,
IP
address,
executor,
architecture,
platform
and
last
contact.
A
The
only
row
or
yeah.
The
only
column
that
I
would
want
there
to
be
sorting
on
is
last
contact
because
for
our
Edge
case,
which
Pedro
shared
with
us,
there
could
be
76
runners
in
a
group
and
it's
most
likely
that
a
lot
of
those
are
stale.
So
if
we're
able
to
sort
by
last
contact,
it's
probably
our
easiest
way
of
showing
which
ones
have
contacted
gitlab
first,
so
that
people
have
those
as
the
most
important
ones.
A
So
we
can
talk
about
that
as
well,
but
I
think
you
all
know
better
than
I
do
about
how
many
we
should
limit
in
this
table
performance
wise
before
we
switch
to
the
next
page
and
then
the
next
thing
here
is
the
jobs
page.
So
we'd
add
the
system
ID
column
into
this,
so
that
admins
get
an
idea
of
which
Runner
manager
is
running
each
job
and
then
the
last
thing
here
is
when
you
delete
a
runner
group,
you
should
get
a
confirmation
modal,
that
you're
deleting
more
than
just
one
Runner.
A
A
Okay,
so
I
think
that's
it.
I
did
want
to
point
out
some
other
things
that
I
added
here
like
feature
usage,
metrics
I
really
would
like
to
add
instrumentation
to
the
accordion
in
the
runner
Details
page
that
expands
and
collapses
the
table
of
all
of
the
runners
I.
Think
if
we're
able
to
add
tracking
on
that-
and
we
see
that
there's
a
lot
there's
a
high
usage,
we
could
consider
reevaluating
where
those
details
go.
A
I
think
we
should
also
add
instrumentation
to
the
delete
button
for
each
runner
in
the
group.
So
again,
that's
within
the
accordion
areas
to
open
this
back
up
this
button.
I
think
this
will
help
us
track.
How
often
people
are
using
that
if
it's
not
used
and
people
are
just
relying
on
the
automatic
deletion
that
that
we're
going
to
add
into
here,
then
we
could
get
rid
of
it.
We
don't
have
to
support
it
and
then
the
last
thing
here
was
I'd
like
to
I.
A
That
might
also
give
us
more
insight
into
why
or
what
people
are
trying
to
do
with
groups
of
Runners
if
they're
coming
in
The,
Details
page
more
often,
they're
likely
also
expanding
this
so
I
think
that
would
help
us
figure
out
the
path
that
users
are
taking
and
what
their,
what
they're
doing
in
the
UI,
when
they're
dealing
with
groups
of
runners
and
then
I'm
hoping
that
we
will
still
no
longer
see
a
bunch
of
Runners
clogging
up
the
UI,
which
was
reported
in
the
kubernetes
issue
and
then
also
I
still
want
admins
to
be
able
to
get
the
information
if
there's
a
problem
going
on
with
the
runner
from
the
list
view.
A
So
that's
why
again.
I
was
like
pushing
to
summarize
this,
but
if
they
need
more
information,
we
still
give
that
to
them
by
drilling
down
so
I
I
feel
pretty
confident
in
this
proposal
still
and
I
think
simplifying.
It
was
the
best
path
forward,
so
I
think
I
answered
everything
yeah.
Thank
you
again
for
all
of
the
feedback
and
discussion
around
this
and
I
think
we
are
gonna
land
in
a
good
place
for
the
MVC.