►
Description
Nadia, the Product Designer at GitLab, shares her insights around the job dependencies view in the pipeline graph and the pipeline optimization workflows.
A
So
today
I'm
gonna
share
with
you
some
of
the
insights
that
we've
uncovered
during
the
solution:
validation,
research,
study
for
the
pipeline
visualization
or
the
pipeline
graph.
So
initially
we
wanted
to
focus
specifically
on
the
job
dependency
issue
in
the
pipeline
graph,
but
we
ended
up
getting
a
lot
of
feedback
around
the
pipeline
graph
in
general
and
around
the
whole
use
case
of
optimizing,
your
pipeline
or
the
workflow
of
optimizing
your
pipeline.
A
So
first
things.
First,
just
some
details.
What
we
did
was
we
interviewed
five
youtube
users
around
their
experience
with
the
pipeline
graph
and
their
needs
around
platform
visualization,
and
we
recruited
them
from
a
feedback
issue
where
they
provided
their
feedback
asynchronously
already,
so
we
just
followed
up
with
them
to
ask
some
additional
questions.
A
So,
first
off
we
uncovered
some
new
jobs
to
be
done
related
to
python
optimization.
So
the
first
one
is
when
optimizing
the
pipeline
for
my
team.
I
want
to
identify
the
existing
and
missing
dependencies,
so
I
can
shorten
the
critical
path
for
the
pipeline
and
these
jobs
to
be
done.
They're
just
drafts,
so
I
I
understand
that
the
wording
might
be
a
bit
off,
but
we
will
be
working
on
them
further
before
we
add
them
to
our
handbook
page.
A
Another
step
to
be
done
is
when
a
job
the
pipeline
fails.
I
want
to
view
all
of
its
related
jobs
to
quickly
identify
the
root
cause
of
the
failed
job.
So
these
two
jobs
to
be
done.
I
see
them
as
like
two
main
use
cases
for
the
job
dependencies
view
of
the
pipeline
graph.
Basically,
so
the
first
is
using
it
to
optimize
your
pipeline
architecture,
because
you
can
see
all
of
the
different
job
dependencies
and
another
one
is
just
a
developer
running
a
merge
request
pipeline.
A
You
might
want
to
investigate
why
a
job
failed
and
by
viewing
the
dependencies
highlight
you
can
see
which
jobs
are
related
to
that
failed
job
like
what
led
to
this
job
failure,
so
you
could
kind
of
narrow
down
and
look
at
only
the
jobs
that
are
related
to
the
job
that
failed
and
another
one
related
to
performancation
is
when
viewing
a
running
pipeline.
I
want
to
see
how
long
a
job
took
or
how
long
a
job
needs
to
wait
to
start.
A
So
I
can
identify
bottlenecks
and
optimize
the
pipeline
critical
path,
so
this
has
to
do
with
perhaps
surfacing
these
additional
insights
somehow
to
these
users
to
make
it
easier
for
them
to
optimize
their
pipeline
critical
path
and
all
as
a
whole.
I
think
every
user
probably
mentioned
the
pipeline
critical
paths
as
important
to
them
as
part
of
their
pipelining
station
and
another
one.
Another
job
to
be
done
has
to
do
with
collaboration.
A
I
want
to
share
the
pipeline
around
insights
with
my
collaborate
on
pipeline,
optimization
or
debugging,
so
that
has
to
do
with
an
actionable
insight,
actually
that
we
have
to
make
the
job
dependencies
view
linkable.
So
we
want
to
be
able
to
share
the
job
dependencies
view,
so
you
can
just
copy
the
link
and
share
with
someone
from
your
team
and
take
you
directly
to
the
job
depends
with
you.
A
A
But
one
interesting
insight
is
that
users
wanted
to
be
able
to
test
the
pipeline
in
different
contexts
to
test
and
optimize
the
pipeline
for
realistic
scenarios.
So
the
job
defensive
view
the
graph
it's
a
graph
for
a
running
pipeline
which
allows
you
to
see
the
graph
of
a
real
pipeline
that
runs
facing
certain
conditions.
A
So
let's
say
you
run
a
pipeline
based
on
some
news,
or
maybe
it's
an
emergency
quest
pipeline
or
the
scheduled
pipeline,
or
we
have
for
all
kinds
of
different
pipelines
and
users
who
are
optimizing
pipelines
that
would
like
to
be
able
to
do
that
before
they
actually
run
the
pipeline.
So
they
would
like
to
be
able
to
set
certain
conditions
on
their
pipeline.
A
Similarly,
the
it
seems
like
the
needs
tab
graph,
like
the
older,
dag
visualization,
that
we
have
it's.
No
it
does.
It
no
longer
provides
additional
benefit
compared
to
the
job
dependencies
view,
because
we're
solving
the
same
problem
in
the
job
dependency
beyond
the
pipeline
graph.
So
now
it
seems
like
this
older
graph
is
a
bit
redundant.
A
Yeah,
it's
the
insights,
confirmed
that
users
would
like
to
see
the
dependencies
in
the
graph
by
default,
so
we
should
explore
ways
to
show
show
those
dependencies
without
having
to
toggle
in
that
new
generally,
we
should
start
exploring.
How
can
we
surface
more
information
around
pipeline
efficiency,
whether
in
the
pipeline
graph
or
the
pipeline
editor
graph?
So
that's
another
kind
of
related
idea.
A
It's
not
an
actionable
insight,
but
I
still
highlight
it
here
is
that
we
also
have
the
pipeline
editor
visualization,
which
is
a
graph
that
is
generated
just
based
on
your
config
and
not
the
final
resulting
running
pipeline
and
right
now
we
see
that
users
rely
on
the
running
pipeline
graph
to
optimize
their
pipeline
configuration.
But
if
we
were
able
to
surface
more
insights
and
more
accurate
pipeline
visualization
in
the
pipeline
editor
it
would.
A
It
could
be
even
more
helpful
because
then
you
can
get
those
insights
without
running
the
pipeline,
which
of
course
would
have
to
involve
us
creating
some
kind
of
mechanism
to
test
your
pipeline
in
a
different
context.
So
it
gets
really
complex,
but
still
there's
something
that
we
should
start
looking
at
and
yeah.
A
Another
important
one
was
that
jobs
that
have
inclusion
dependencies
should
show
up
in
correct
order
in
the
graph
right
now
there
they
just
show
up
in
the
first
column,
which
was
confusing
for
many
of
the
users
and
related
to
that
we
want
to
show
implicit
dependencies
yeah.
So
it's
it's
this
insight
right
here.
A
We
want
to
show
implicit
dependencies
between
jobs
that
are
based
on
stages
and
not
only
based
on
needs,
because
when
you're
optimizing
your
pipeline,
you
want
to
see
all
of
your
dependencies
and
you
want
to
be
able
to
differentiate
between
them.
So
you
can
say,
decide
to
replace
a
stage-based
dependency
with
the
needs-based
dependency
if
it's
more
efficient
for
you
or
maybe
the
other
way
around.
A
However,
we
need
to
be
careful
here
because
at
the
same
time,
we
don't
want
to
overload
just
a
developer
running
emerge,
request
pipeline
with
this
information,
because
they
just
want
to
see
the
dependencies
and
they
don't
really
care
about,
whether
it's
implicit
or
explicit,
and
how
it's
set
up
in
the
config
yeah.
So
these
are
the
main
themes.
A
There
are
some
other
insights
here
that
I
haven't
covered
but
feel
free
to
dive
deeper
into
them,
and
check
out
the
actionable
issues
that
I've
created
to
see
what
we're
gonna
do
with
these
insights
and
how
we're
gonna
use
them
to
improve
the
experience
for
optimizing.
Your
pipeline
and
generally
visualizing
the
pipeline
run
and
helping
you
with
debugging
the
jobs
that
are
failing.