►
From YouTube: CI/CD UX Team Design Review | 4 February 2020
Description
Design Review session of CI/CD UX Team.
- Dimitrie Hoekstra | 00:35
DAG pipeline visualisation
A
B
B
B
Which
one
is
it
this
one
should
be
alright,
so
now
to
the
presentation:
hi
welcome
new
troops,
RAF
product
designer
verify
continuous
integration.
So,
let's
jump
right
into
the
next
one.
Dag
visualization
is
the
issue
we
need
to
we're
intending
to
build
in
12
of
Mines
for
doing
the
ideation
right
now,
there's
been
research.
That's
come
before
it
before
that.
Let
me
explain
a
little
bit.
B
What
a
directing
secret
graph
is:
it's
a
finite
directed
graph
with
no
directed
cycles
as
wikipedia
states,
so
basically
each
job
can
depend
on
any
other
jobs,
and
this
gives
user
a
lot
of
flexibility
right.
So
they
can
have
a
little
bit
more
of
flexible
structure
in
their
pipelines.
Instead
of
all
jobs
in
the
stage
depend
on
all
other
jobs
of
the
previous
stage,
and
this
kind
of
helps
them
remove
any
bottlenecks.
Is
there
in
their
pipeline
so
quickly.
Let's
see
what
has
happened
in
the
past
in
1202,
we
had
the
MVC
implementation.
B
B
So,
let's
quickly
jump
in
here's
an
example
of
a
mini
pipeline
graph
and
the
full
pipeline.
Where
you
see
multiple
stages,
jobs
are
starting,
but
their
lines
is
like
a
CSS
bug,
but
even
if
that
was
fixed,
there's
not
really
clear.
Why?
For
example,
they
review
prepare
stage
job
instead
of
inside
of
there
it's
starting
while
the
jobs
before
that
in
post-test
stage
are
also
still
running.
So
it's
one
of
those
problems.
We're
trying
to
fix
the
business
decision
I'll
quickly
go
through
this.
B
We
want
to
basically
avoid
creating
different
modes
and
also
fourth
confusion,
as
we
currently
have
there's
a
clear,
initio
or
initiative
to
to
move
forward
with
this.
The
hypothesis
there's
confusion.
Yes,
there
is
Laurie
has
found
that
out
for
sure
and
people
use
final
stage
to
see
the
status
to
troubleshoot
pipeline
failures.
That
is
indeed
true,
but
they
also
need
to
find
out
a
little
bit
more
right.
They
need
to
have
that
dependencies
visible
and
in
order
to
see
how
the
pipeline's
was
architected
or
even
to
troubleshoot
certain
jobs.
B
B
So
some
highlights
of
what
we
found
out.
You
know
it's.
The
order
of
jobs
is
important
to
know
both
for
troubleshooting
and
for
the
apartment,
architecture,
architecture,
status
and
progress
are
important.
This
is
not
something
just
from
this
research,
but
is
a
thing
that's
coming
on
from
multiple
so
interesting
to
to
make
any
changes
into
this.
For
you
know
multiple
reasons,
let
me
see
it's
a
visual
model.
That's
the
one
actually
to
edit
in
this
presentation
doesn't
make
much
sense.
This
one,
but
let's
see
the
current
workarounds,
is
kind
of
like
the
interesting
one.
B
B
This
were
you
know
some
of
the
insights
coming
out
of
the
research
we're
in
this
direction.
I
do
think
that
this
is
currently
out
of
scope,
but
there
is
a
high
need
for
this.
You
know
where
is
the
bottlenecks
happening,
but
also
you
know
which
jobs
are
taking
very
long,
and
this
I
think
this
dag
will
eventually
already
set
the
first
step
in
that
direction,
where
you
can
see
hey
this
job,
which
has
an
insanely
long
execution
time,
but
also
has
many
jobs
dependent
on
this.
You
know
that
is
a
high.
C
In
there
sorry
for
interruption,
but
Jessica
question
just
make
sure
that
everyone
on
the
call
knows
what
that
stands
for
and
like
what
it
is
actually
because
I
wasn't
aware
before
talking
to
you
on
this
issue.
Of
course,
just
yeah
I
know
that
probably
you
will
dive
into
that
a
bit
more,
but
just
yeah.
B
So
there
is
a
direction
inside
of
the
pipeline,
but
the
jobs
themselves
can
now
independently
depend
on
other
jobs
instead
of
complete
stages,
and
it
kind
of
is
shown
here
a
little
bit
in
the
top
right
where
you,
for
example,
if
you
have
one
two,
three,
four,
five,
six,
seven,
eight
nine
jobs,
while
the
four
last
job
depends
on
two
other
jobs.
So
it
depends
on
the
one
directly
going
before
it
and
another
job
before
that,
and
it's
the
same
one
with
the
last
one
right.
B
A
A
C
C
B
Then
we
have
the
pipeline
models.
This
one
is
actually
interesting
for
one
specific
one,
which
is
this
last
one.
So
we
have
the
stage
base
approach.
You
know
the
current
pipelines
can
still
remain
stage
based
if
we
want
this
new
capability,
which
we
already
support,
is
you
know
DAG
jobs
or
jobs
depending
on
just
jobs
instead
of
stages,
and
then
we
have
the
hybrid,
where
we
can
do
both
at
once.
We
currently
support
you
know
bags
being
just
dependent
on
our
legs.
B
B
So
it's
kind
of
like
going
in
between
the
hybrid
and
making
the
dependability
a
little
bit
more
flexible,
but
it
isn't
really
super
relevant
to
the
current
problem
space,
but
it
is
interesting
to
point
out
because
I
think
the
graph
should
be
able
to
support
this,
regardless
of
us
supporting
this
in
the
in
the
CI.
So
if
we
decide
to
implement
it,
it's
easy
to
implement
and
the
front
end
is
already
capable
of
showing
it
I
don't
want
to
spend
too
much
time.
B
So,
if
you
have
questions
about
this,
I
would
say:
let's
put
it
at
the
end,
because
it
is
less
about
this
problem
space.
Currently,
the
jobs
which
we'll
focus
on
is
a
pipeline
graph.
That
is
the
main
evidence
space
where
the
user
will
go
both
the
implemented
persona,
as
well
as
user
persona,
and
in
order
to
figure
out,
you
know,
hey
what
has
gone
wrong
right
or
hey
how's.
My
pipeline
architected
many
pipeline
grabs
more
basically
for
troubleshooting
what
is
in
progress,
so
there
are
more
for
user
persona.
B
So
there's
already
one
persona
missing
I
would
say
for
now
we're
going
to
keep
this
out
of
scope
as
well
as
that
it
already
kind
of
works
with
a
dag
as
well,
because
there
is
the
how
the
system
currently
works.
Even
if
you
don't
define
a
stage
for
a
certain
job,
for
example,
of
dag
job,
because
it
doesn't
really
make
sense,
the
system
will
still
define
it
a
stage
that
will
define
the
first
stage,
which
is
made
most
of
the
time
test.
B
It
will
have
that,
and
in
that
way
it
will
always
show
up
in
many
pipeline
graphs.
So
it's
not
something
that
we
break.
Currently,
it
will
just
look
a
little
bit
funny,
but
it
kind
of
shows
away
like
hey,
there's
logical
grouping
which
in
this
case
is
the
manual
stages
and
you
will
be
able
to
figure
out
hey
in,
for
example,
all
the
stage
with
all.
B
Which
which
fails
and
gains-
and
we
find
that
out
by
the
way,
did
you
hear
me
still
I
see
my
my
audio
is
giving
me
some
problems
here.
It
seems
we
lost
you
for
last
15
seconds.
Okay,
some
reason
that
iPods
for
connecting
so
the
idea
here
is
basically
we'll
focus
on
the
pipeline
graph,
because
the
rest
is
interesting
to
look
into,
but
its
secondary
and
will
result
in
a
lot
of
scope,
creep
and
I.
Think
the
pattern
graph
will
have
the
highest
priority
here
again.
B
What
information
we
present,
this
I'm
listening
this
more
as
hey.
If
you
see
if
I'm
missing
anything,
please
let
me
know
a
thing
as
possible
thinkers
as
well
as
well
possible
when
they
depict
the
status
the
dependencies
right,
which
jobs
and
before
this
job
was
triggered
the
stage.
If
any
I'm
gonna
go
a
little
bit
away.
That's
deeper
topic,
you
know:
are
we
gonna
show
that
stage
which
is
kind
of
induced
by
the
system?
If
we
have
a
pure
dag
pipeline,
that
is
no
longer
necessary,
but
it's
interesting.
B
Perhaps
this
show
a
type
so
it
see
their
job
and
job
grouping.
So,
for
example,
if
multiple
jobs
have
a
certain
naming
pattern,
their
concatenated
into
a
single
node
to
make
the
pipeline
graph
a
little
bit
more
wieldy
a
project,
for
example,
upstream
and
downstream,
and
a
child
pipe
in
which
we
kind
of
visualize
in
the
same
way,
but
they
both
have
this
trigger
job
before
it,
which
kind
of
like
triggers
that
action
element
so
action
buttons.
B
B
Characteristics.
I,
think
this
is
one
of
the
more
interesting
slides
here.
You
know
we
want
to
be
able
to
see
how
the
pipelines
are
architected
in
a
you
know,
quick
and
efficient
way,
and
what
the
path
towards
a
certain
job
is.
So
it's
kind
of
nice
that
it
needs
to
work
for
both
small
and
huge
graphs.
B
The
pipeline
graph
from
gitlab
is
already
pretty
big,
but
I
suppose
that
some
of
our
clients
have
even
bigger
pipelines
to
attend,
to
and
and
perhaps
make
use
of,
Hmong
repose
dependency
line
should
have
clear
an
expected
structure,
sort
of
cognitive
loads
which
stays
minimal.
I
think
this
is
kind
of
interesting.
If
we
look
at
one
of
the
earlier
or
the
examples,
I'll
show
a
feature
you
can
see
that
some
of
those
crabs
do
not
have
this
required
this
this
characteristic
to
them
and
make
them
harder
to
read
and
there's
a
clear
in
the
direction.
B
I
think
this
is
pretty
interesting.
One
of
the
examples
I'll
show
will
will
have
this
immediately
and
some
others
as
well,
while
others
have
do
not.
This
is
a
directed
acyclic
graph,
so
it
will
have
a
direction
to
it.
I
think
it's
kind
of
nice
that
we
can
potentially
visualize
this
without
resorting
to
no
arrows
and
then
like
hey
the
direction
is
top-down
or
left-to-right.
This
kind
of
should
be
clear
from
the
structure
of
the
author
of
the
graph.
Basically,
let
me
see
which
other
things
are
kind
of
important.
You
know.
B
Accessibility,
of
course,
interact
ability.
Perhaps
you
want
to
be
able
to
zoom
stretch
things
out.
Action
items
should
be
possible
to
click
into
this
kind
of
like
important
for
front
end
for
feasibility,
and
you
know,
of
course
this
one
is
kind
of
interesting
if
a
job
has
multiple
other
jobs
depending
on
it,
that
job
should
become
more
visible,
because
that
is
a
more
high-risk
job.
B
If
that
job
fails
or
if
that
job
is
taking
long,
you
know
we
want
to
know
immediately
or
as
soon
as
possible,
because
that's
a
it's
a
high-risk
item
and
we
have
some
solutions
for
that
in
the
future
pipeline
graph.
I'm
gonna
skip
this
one
because
I'm
I
said
before
this
is
alpha
scope
for
now.
So
let's
look
at
some
bags.
Here's
a
kind
of
like
a
simple
version
in
the
left
top
corner
and
in
the
bottom
right
corner.
There's
a
little
bit
more.
You
know
more
complex
wanna.
B
You
can
immediately
see
with
the
more
nodes
added
and
more
dependency
lines
at
it.
Things
quickly
add
up
to
a
more
complex
structure
and
also
the
direction
in
this.
This
right,
one
is
very
hard
to
to
gouge
and
it
basically
it's
all
over
the
place,
and
it's
not
easy
to
read.
Basically,
the
the
graph
will
look
differently.
Every
time,
you're
gonna
look
at
it
based
on
the
amount
of
nodes
it
has
and
how
it
executed.
So,
there's
some
downsides
to
that
one.
B
So
logical
groupings,
right
stage
based
grouping
is
kind
of
limiting
to
DAGs
doesn't
really
make
sense.
It
is
something
that
the
user
has
intended,
but
the
system
might
be
able
to
show
us
far
more.
You
know
efficient
ways
to
kind
of
scan
the
graph
for
troubleshooting
and
pipeline
architecting
or
order
of
execution
right.
So
here
are
some
ideation
examples.
B
For
example,
we
here
I
focused
in
on
for
somebody
which
ones
are
completing
which
are
running
which
are
directly
next
up
and
which
are
you
know,
waiting
on
multiple
dependencies
to
finish
up
first
kind
of
like
a
downside
is
that
eventually
all
end
up
in
the
completed
column,
which
makes
then,
after
you
look
at
a
completed
pipeline,
it
totally
unreadable,
but
it
was
interesting
to
look
into
here's
one
which
kind
of
like.
Has
this
Gantt
chart
going
on
where
you
can
see
you
know
performance,
optimization
going
on,
you
know,
jobs
will
take
longer.
B
B
You
know
hey
what
if
we
highlight
certain
ones,
for
example
here
in
the
bottom
one
you
can
see
hey
what
are
the
direct
dependency
paths
towards
this
highlighted
node
here,
it's
kind
of
interesting
what
you
can
do
with
the
interaction
of
a
graph,
and
then
we
here
we
have
the
more
you
know
complex
one.
You
can
easily
see
how
it
becomes
kind
of
hard
to
visualize.
Keep
that
direction
going.
There's
a
lot
of
things
that
you
know
you
can
easily
be
hard
to
read,
but
this
generation
dependency
generation
is
still
quite
clear.
B
So
I
looked
into
this
this
this
tool,
which
is
called
observable.
There
are
some
similar
tools
which
I
think
are
more
familiar
with
Python
this
one.
You
use
a
lot
of
Java
scripts
and
NPM
packages
if
I'm
right.
But
what
did
this
is
is
basically
in
note
tool
with
little
life
code
base
in
it.
It
allows
us
to
live
play
with
with
other
examples,
so
P
I've
uploaded
these
kind
of
examples
where
they
created
bags.
B
In
a
linear
fashion,
or
the
one
that
we've
seen
before
or
this
one
on
the
right
evening,
which
is
more
of
like
a
graph,
node
and
kind
of,
has
some
direction
to
it,
a
lot
of
text
and
it's
good
like
there's
different
examples
to
be
found.
However,
then
I
found
this
one,
which
is
kind
of
pointing
us
into
the
right
direction.
You
know
the
things
have
a
clear
direction,
easy
to
read.
It
has
this
dependency
thing
on
going,
so
we
can
easily
see
hey.
You
know.
B
Chaos
is
the
first
route
generation,
while
the
other
ones
depend
on
that
and
so
forth.
And
then
we
have
the
right
one,
which
is
kind
of
like
goes
into
this
Metro
kind
of
style,
where,
for
example,
if
a
metro
station
has
more
lines
that
go
away
from
it,
that
metro
line
station
visualization
or
that
you
know
that
abstract
visualization
of
that
metro
station
will
become
bigger
and
will
become
more
physical.
B
One
of
the
characteristics
that
we
were
looking
before
so
I
played
around
with
this
little
and
instead
of
like
family,
where
you
know
you'll
always
have
two
parents-
and
you
know
new
people
are-
will
be
married
to
you,
know
children
that
doesn't
make
sense
for
our
pipeline
kind
of
way
where
we
want
to
see
alright,
which
jobs
are
the
first
generation
of
dependents,
which
basically
jobs
without
a
route
dependency,
and
then
the
second
one
and
the
third
one.
However,
the
problem
here
was
there's
somewhere.
B
Something
where
I
need
front-end
to
to
work
with
me
is
that
the
script
of
this
pipeline
visualization
is
not
yet
up
to
the
task
for
this,
and
it
creates
these
glitches.
But
it
kind
of
shows
us
the
way
that
we
can
here's
a
little
bit
of
a
simpler
one.
It's
the
relatively
complex
one,
and
you
can
immediately
see
here
what's
going
on,
but
the
script
is
not
yet
up
to
up
to
par
again.
What
we
do
we
need
to
show
I
think
this
is
kind
of
interesting.
B
No,
how
can
we
hack
the
system
a
little
bit
the
stage
header,
for
example?
How
can
we
show
this
hybrid
kind
of
thing
right
where
we
have
both
dag
jobs
as
well
as
stage
based
jobs,
and
this
is
where
ideated
into
the
into
the
following
proposal,
where
we,
for
example,
can
see
hey?
This
is
job.
These
jobs
depend
in
this
stage,
but
you
know
this
job
depends
on,
for
example,
this
stage.
Basically,
this
is
the
one
that
I
should
not
support
yet,
but
hey.
B
This
was
quickly
thrown
together
eventually,
and
this
is
something
I
would
like
to
have
feedback
on
in
terms
like
hey.
Do
you
see
any
immediate
problems
with
this?
Is
this
too
much
information
or
not?
But
you
can
see
here,
for
example,
with
this
job
in
the
bottom,
where
it
has
not
run
yet
that
it
will
have
the
dotted
lines
and
it
will
have
multiple
jobs
depend
on
this
job.
This
job
will
have
no
dependencies.
It's
part
of
this
stage
group.
These
kind
of
things
are
all
possible
and
there's
the
trigger
job.
B
The
project
name
for
like
a
downstream
pipeline,
for
example,
which
can
be
expanded
and
then
show
in
line
I,
think
we
have
a
real
opportunity
here
to
do
the
right
thing,
with
downstream
pipelines
as
well,
which
can
already
expand
in
line
as
well
as
upstream
models.
But
now
we
have
this
kind
of
like
dynamic
graph
visualization,
which
will
be
able
to
expand
and
adjust
based
on
the
information
present.
B
Lastly-
and
it's
this
last
slide,
what
is
up
next,
so
solution,
validation
after
we've
implemented
it,
because
it's
scheduled
for
12:00
at
9:00?
Let's
look
into
have
we
actually
solved
the
problem
or
what
remaining
problems
are?
Are
there
and,
of
course,
the
things
that
we're
out
of
scope,
different
logical
groupings
and
different
visualizations,
for
example,
for
performance?
Optimization
and
that's
it
kind
of
like
a
big
project
but
I
think
a
very
interesting
puzzle
to
solve
that
will
heavily
depend
on
feasibility.
Its
front
end
and
back
end
back
end
will
have
less
problems.
B
E
It's
super
interesting.
It's
like
well
really
neat,
you
and
I
remember
when
we
first
discussed
about
like
upstream
and
downstream
so
I
plan,
but
I
never
thought
it
could
get
this
complex.
My
first
point
is
not
really
a
comment,
but
it
yeah.
You
confirm
this
I
thought
when
you
start
showing
it
was
subway
map
right.
So
all
the
jobs
want
to
reach
a
final
destination,
and
it
would
make
sense
that
things
would
think
like
connect
that
way.
So
it
was
nice
that
you
showed
that
yeah
like
a
super
complex
for
you,
so.
C
E
Yeah
I
wrote
my
comment
before
he.
He
showed
it's
a
slight,
but
that
kind
of
connects.
My
next
point,
which
is
a
question
as
for
this
ideation,
have
you
considered
like
how
people
will
interact
with
this
page
because
you
show
the
expanding
collapse
right
on
the
upstream
and
downstream
pipelines,
but
I'm,
not
sure
if
you
mentioned
I,
don't
know
any
exploration
regarding
like
zooming
in
or
out
and
paint
she
and
swiping,
because
we
know
that
the
area
on
the
interface
and
I'm
only
thinking
about
the
interface.
Now
it's
super
limited.
B
B
You
know,
hey
what
does
front
and
think
is
feasible
for
an
MVC
and
for
now
this
is
why
I
you
know
this
kind
of
proposal
seems
kind
of
slim,
but
has
a
lot
of
information
in
there.
You
know
hey
how
what
is
each
individual
building
blocks
so,
for
example,
this
stage
thing
is
a
building
block
the
job
itself.
This
this
little
node,
which
expands
for
you,
know
the
multiple
lines
how
it's
being
structured,
then
you
haven't
need
the
downstream
pipelines
which
is
expendable.
B
This
is
actually
one
of
the
few
example
which
is
in
the
ashes
show
has
some
interaction
to
it,
but
the
current
graph
has
that
as
well.
So
I
thought
it
was
kind
of
necessary
to
show,
but
I
want
to,
though,
does
not
really
shows
yet
the
individual
building
blocks
by
itself.
I
think
this
is
kind
of
like
the
first
step
needed
for
to
have
an
interesting
discussion
with
front-end
to
see
like
hey.
Can
we
actually
do
this
and
look
at
this
code
I
found
and
created
those
graphs
with?
Is
this
usable
at
all?
B
Can
we
expand
this?
There
are
some
problems
existing
with
it
with
the
current
with
the
current
scripts,
as
you
can
see
here,
but
also,
if
we
look
into
here,
some
lines
overlap
unnecessarily,
which
will
create
confusion
so
yeah,
so
the
bay,
the
TLDR
I,
did
not
go
too
far
yet
because
it's
heavily
dependent
on
on
feasibility
discussions
before
I
go
further,
but
yes,
I
intend
to
for
those
which
these
interactions
to
become
a
possibility
for
sure.
That's.
B
It's
it's
kind
of
interesting
right.
The
the
colors
as
depicted
here
kind
of
only
souls
the
the
use
case
of
hey
I,
want
to
be
more
easily
follow
my
dependency
line.
It
is
not
so
much
that
the
color
defines
a
true
meaning
other
than
it
needs
to
a
different
kind
of
shade
or
different
kind
of
like
basic
color
than
another
line,
but
I
wanted
to
make
sure
that
we
don't
make
mistakes
basically,
so
it's
more
like
a
check
like
hey.
B
C
It
helps
me
to
understand
that
the
whole
thing
better
but
they're
only
like
fear
that
I
have
it's.
There
is
a
lot
of
like
information
in
matrix
that
we
would
want
to
communicate
to
the
user
with
this
visualization.
So
I
was
curious.
You
know
like
how.
How
are
we
going
to
be
explaining
the
dotted
line?
What
does
that
mean?
Maybe,
like
other
statuses
or
like
assignees
I,
don't
date,
if
needed,
all
of
those
metrics
that
you
showed
in
the
presentation.
Probably
that's
something
to
think
about.
Yeah.
B
I
think
so
as
well.
Basically,
we
need
to
make
I
need
to
make
an
inventory
of,
like
all
the
different
data
we
want
to
show
and
how
it's
like
makes
up
in
terms
of
building
blocks.
How
are
visualized,
for
example,
the
dotted
lines
if
a
job
has
not
been
or
has
failed,
or
it's
not
being
completed
yet
or
is
yet
to
run,
for
example,
a
manual
job.
The
the
line
that
will
follow
up
follows
out
of
that
job.
So
we'll
you
know
if
say
their
job
runs
and
it
runs
successfully.
B
Then
this
next
job,
which
is
dependent
on
this
job,
we'll
run
it
it's
kind
of
like
what
this
dotted
line
will
show
and
I
hope.
What,
for
example,
become
possible
is
that
if
the
the
pipeline
is
running
and
it
completes
and
the
job
changes
to
a
successful
job,
then
that
dotted
line
will
become
suddenly
a
solid
one.
B
So
that
will
be
a
subtle,
CSS
change,
something
which
will
should
be
easily
done
in
real-time,
but
it's
kind
of
like
in
that
way
teaches
the
user,
the
meaning
of
a
dotted
line
without
it,
as
explicitly
stating
and
in
the
in
the
UI,
with
the
legend
or
something
like
that,
though
you
know,
if
it.
If
it
remains,
you
know
hard
to
read
or
not
clear
I
hope
we
catch
those
things
with
a
potential
solution.
Validation,
exercise.
C
F
I
have
been
trying
to
figure
out
what
particular
I
want
to
say
it,
but
I
wanted
to
call
out
that
I
think
just
like
Nadia
and
Hana
the
subway
metaphor,
one
it
100%
registered
with
me
to
because
Boston
in
San
Francisco
Amsterdam.
They
all
look.
The
same.
Look
like
that,
which
is
great
I,
was
trying
to
think
on
the
interaction.
When
you
look
at
a
single
job
detail,
it
would
be
kind
of
interesting
if
all
of
the
other
paths
faded
out,
maybe
like
half
opacity.
F
B
A
little
bit
into
this,
let
me
see,
find
it
so
this
one
here
in
the
bottom
right
corner.
You
see
that
the
other
lines
have
been
dotted
well,
the
one
that
directly
connects,
but
you
mean
towards
the
root
job
right
towards
they
know
the
initial
job
that
started
a
lot
that
all
the
way
up
towards
the
current
job,
I
think
yeah.
B
G
Came
out
of
the
research
I
think
if
I
can
remember
correctly
that
they
also
wanted
to
use
this
to
troubleshoot
and
troubleshoot
quickly,
so
they
needed
to
be
have
a
way
to
like
zoom
in
or
focus
on
the
thing
that
failed
and
figure
out.
What's
what
is
it
infecting
and
then
what
made
it
fail?
So
not
only
looking
at
the
context
around
it,
but
also
diving
into
that
job
easily
in
figuring
out
what
happened.
B
B
Well,
as
you
know
like
we
don't
want
to
per
se
deprecated
stage
based
pipeline
models,
they
need
to
be
able
to
to
co-exist
as
they
already
are
supported,
but
perhaps
to
give
you
the
best
look
into
that
is
kind
of
go
a
little
bit
into
detail
on
it
here,
where
I
edited
the
the
graph
of
the
the
previous
one.
So
basically
this,
for
example,
I
know
it's
a
little
bit
fast,
but
here
we
can't,
for
example,
see
hey
prepare
here
is
the
stage
header
and
then
the
jobs
under
it
will
be.
B
It
will
mean
that
they
are
part
of
this
stage
well,
for
example,
future
jobs
that
are
dependent
on
one
of
those,
for
example,
though
they
are
here
part
of
the
build
job
or
build
stage,
they
can
also
be
have
other
jobs
depend
on
jobs
within
a
stage.
I,
go
a
little
bit
more
into
detail
on
this,
or,
for
example.
B
A
All
yeah
I
would
like
to
see
I
think
the
hybrid
one
is
like
you
know.
The
Holy
Grail,
but
I
would
also
like
to
see
an
example
here
of
like
the
pure
stage,
one
right
to
make
sure
that
we
don't
go
down
right.
I!
Think
that's!
That's
where
we're
that's,
where
we
are
doing
a
good
job
two
days.
I
just
want
to
make
sure
that
that
experience
stays
as
par
or
goes
up,
yeah.