►
From YouTube: CI/CD UX Meeting - 2021-09-22
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
Right
this
is
the
cicd
ux
meeting
for
september
22nd.
Let's
see
a
couple
of
announcements,
read
only
gina
shared
her
journey
of
prioritizing
her
work
for
runner.
She
learned
a
lot
she's
still
and
going
process
that
with
there
on
her
pm
and
finally
landed
in
a
solid
plan.
A
So
I
saw
some
comments
in
slack,
but
please
have
a
look
if
you
haven't
done
so
and
contribute
with
the
regina
async,
and
will
it's
not
here,
but
I'm
gonna
voice
his
points
for
research,
ongoing
issue
with
ops
and
enable
any
jesus
enablement
research,
so
he
helped
analyze
environment
survey
and
put
data
into
dovetail
he's
also
wrapping
up
the
survey
for
release,
that's
with
daniel,
so
daniel.
Maybe
you
know
we
want
to
unvoice
some
of
these
things
here.
If
it's
not
already
in
your
points,
I
have
a
point
about
that.
A
A
B
Cool
so
the
last
two
weeks
I've
been
working
on
my
onboarding
issue
and
creating
a
ux
scorecard
for
a
package.
So
as
of
today,
I've
completed
all
of
the
tasks
for
both
the
ux
scorecard
and
the
recommendations,
issue
and
they're
both
linked
here.
B
So
please,
everyone
feel
free
to
have
a
look
and
I'd
appreciate
any
feedback
that
you
have,
and
this
has
been
a
really
great
learning
experience
for
me
and
actually
creating
the
project
to
simulate
the
workflow
to
follow
for
the
ux
scorecard
was
like
the
first
time
where
anything
clicked
of
like
what
is
actually
packaged,
because
I
was
struggling
a
lot
with
the
technology.
B
So
that
was
really
helpful
and,
and
I'd
like
to
do
that
with
some
other
parts
of
the
package
project
product,
like
the
dependency
proxy
and
I
think,
looking
ahead
towards
finishing
the
ux
scorecard,
I'm
getting
familiar
with
the
ux
issues.
I
watched
gina's
video
back
about
how
she
prioritized
the
issues
for
her
milestone,
and
so
that
was
really
helpful
and
good
inspiration
for
me,
and
I
started
the
conversation
today
with
my
pm
tim
and
there's
quite
a
lot
of
ux
issues
in
the
backlog.
B
But
we
kind
of
isolated
five
issues
that
align
with
the
direction
that
the
product's
moving
in
and
those
issues
are
quite
variable
in
scope,
and
some
of
them
are
quite
large.
Some
of
them
will
require
problem,
validation,
and
so
the
next
step
is
for
me
to
dive
into
those
issues
and
some
of
the
underlying
technology
and
such
as
the
dependency
proxy,
because
quite
a
few
of
them
have
something
to
do
with
that,
and
I
also
had
a
good
chat
with
nadia
about
how
to
engage
research
and
the
potential
for
generative
research.
B
The
problem
validation
in
the
package,
validation
backlog
is
quite
narrow
in
scope,
and
there
could
be
an
opportunity
for
me
to
learn
more
about
the
product
to
have
a
little
bit
of
a
broader
scope
and
try
to
uncover
any
pain
points
that
package
users
are
facing
so
yeah
after
the
ux
scorecard
I'll
be
kind
of
looking
into
both
the
issues
that
tim's
pointed
out
and
also
trying
to
be
a
bit
proactive
with
generative
research
and
start
to
think
ahead
about
when
I
start
picking
up
work
for
the
package
stage-
and
that's
me.
B
Yes,
I've
recorded
one.
It's.
C
B
Linked
on
the
the
first
issue,
the
ux
scorecard
issue.
D
All
right,
so
thanks
katie
for
sharing,
I
guess
I'm
next
on
the
list.
D
So
my
first
point
is
on
the
problem.
Validation
for
the
environments
page
like
it's
mentioned
by
will
as
well
we'll
just
wrapped
up
the
analysis
for
the
survey.
This
link
here
links
to
the
issue
that
has
kind
of
copy
paste
from
from
that
day,
with
the
main
insights
and
the
main
information,
but
doctor
has
a
little
more
more
info,
so
you
have
access
to
it
over
there
as
well
design
wise.
A
few
insights
that
I
took
from
the
research
insights
were
there.
D
We
needed
clear
separation
and
definition
between
the
concepts
of
environments
and
deployments
on
the
page.
Both
were
equally
mentioned
on
the
on
the
open
questions,
but
deployment
is
really
a
has
a
really
small
footprint
on
the
page.
It's
not
well
defined
it's
a
piece
of
information
in
the
broader
environments
ui.
So
so
we
definitely
need
to
make
that
a
little
bit
stronger
and
then,
in
terms
of
actions.
A
lot
of
what
was
mentioned
was
I
want
to
know
what
is
the
latest
change?
D
I
want
to
know
what
is
the
current
status
or
what
is
changing
now
so
also
giving
more
more
impact
to
that
on
the
ui,
as
we
redesign
another
point
that
was
mentioned
by
users
is
having
an
easier
time
to
start
so.
Users
need
a
better
guidance,
get
started
with
environments
and
to
move
between
the
ui
and
the
docs
as
well.
So
that
really
relates
to
learnability.
D
All
in
all,
just
over
half
of
the
respondents
are
satisfied
with
environments.
Today
I
don't
think
just
redesigning
the
page
will
will
address
that.
It's
it's
bigger
concerns
of
missing
functionality
or
other
pieces
that
have
to
to
to
go
in
there,
because
environment
is
far
bigger
than
just
the
page.
D
But
that's
that's
the
starting
point
that
we
we're
working
from
the
both
the
quant
and
the
qualitative
analysis
are
done,
but
I
want
to
go
a
little
bit
deeper
into
the
qualitative
side
of
it
and
really
go
through
each
one
of
the
of
the
open,
open
questions
that
the
user's
respondents
responded
to
cluster
them
together
and
get
to
some
final,
three
or
four
statements.
D
That
really
summarize,
what
users
are
using
that
page
for
and
that's
what's,
gonna
direct
the
redesign
efforts,
the
most
like
looking
at
these
three
or
four
points:
are
they
being
addressed
by
this
new
design?
Yes
or
no,
and
use
that
as
our
our
north
star?
As
we
do
that
and
then
the
redesign
is
the
point
below
I've
already
started
doing
some
explorations
based
on
the
feedback,
but
still
taking
it
easy,
because
I
don't
want
to
just
go
full
steam
before
really
absorbing
all
this.
D
All
this
context
and
all
this
feedback,
and
also
this
this.
This
effort
is
going
in
parallel
with
a
broader
effort
that
I'm
I'm
working
on
with
vitica
for
for
data
tables,
also
in
pipelines
and
other
parts
of
of
the
product
and
especially
cicd.
D
So
even
though
I
want
to
to
improve
and
redesign
the
environment
stable,
I
also
want
to
make
sure
that
these
improvements
are
well
shared
with
with
other
areas
and
we
can
improve
horizontally,
how
we
deal
with
tables
and
how
we
share
how
we
how
we
deal
with
similar.
D
A
For
gina,
a
lot
of
a
lot
of
the
challenges
in
runner
is
about
consuming
and
managing
data
and
in
the
admin
view
about,
like
hundreds
of
thousands
of
items
and
there's
also
an
effort
that
you'll
be
looking
to
the
upcoming
milestones
about
improving
that
view.
So
there's
an
overlap
there.
So
I
think
it's
a
moment
for
everyone
to
to
come
together.
D
Yeah,
I
think,
regardless
of
of
specific
use
cases
or
even
even
user
goals,
there
are
some
some
walls
that
we
hit
with
regards
to
tables
when
we
have
too
much
data
or
too
much
of
a
specific
kind
of
data,
and
and
these
these
can
be
solved
by
patterns
that
we
can
then
share
horizontally
and
then
apply
to
whatever
case.
We
need
it's
still
very,
very
fuzzy
in
my
head,
but
but
I
will
share
more
more
progress
soon.
C
Danielle
I
was
wondering
if
there's
somewhere,
like
an
overview
of
environments
in
gitlab
kind
of
like
an
explanation
of
what
these
are
and
what
are
the
basic
things
that
like
basic
things
about
environments
or
maybe
there's
a
handbook
page
with
like
a
category
direction
or
something
that
would
be
very
helpful.
Because
I
I'm
looking
at
this.
The
survey
and
I
feel,
like
I'm,
lacking
some
foundational
understanding
of
this
concept
in
gitlab
and
would
be
helpful
to
have
that
information.
D
Yeah,
so
let
me
check
that
there
was
just
an
mr
emerged
that
created
an
environment
management
direction
that
is
really
focused
on
that.
Let
me
see
if
I
can
find
it
I'll
add
to
the
dock
later.
I
also
have
an
mr
to
add
an
environments
object
to
the
pajamas
documentation.
D
It's
been
lingering
for
a
while.
I
have
to
wrap
it
up
and
the
goal
for
that.
Mr
was
really
to
explain
what
the
environment
is
as
a
concept
and
then
as
an
object.
What
pieces
of
information
it
has
and
what's
connected
to
it
so
get
back
to
it
and
once
it's
merged
I'll,
also
share
it
with
you,
because
the
goal
really
for
that.
It's
really
to
address
your
question
like
what
is
an
environment
and
then
and
then
go
from
there.
C
A
D
Thanks
ayanna
and
then
quickly.
The
last
two
points
last
milestone
43.
I
finished
up
the
design
proposal
to
add
deployment,
approval
and
rejection
on
the
environments
page.
This
link
goes
directly
to
the
to
the
main
mockup
for
that
thanks
nadia
for
the
co-working
session,
where
you
give
me
a
bunch
of
really
good
feedback
on
this
really
appreciate
it.
This
was
supposed
to
happen
after
we
did
some
redesign
on
environments.
D
But
since
it's
a
very
very
strongly
requested
feature
by
customers,
then
we
decided
to
just
move
ahead
with
it
and
I'm
happy.
We
did
because
it
was
a
really
good,
iteration
so
happy
to
see
where
it
goes
from
here
last
point:
I'm
working
on
the
the
jobs
to
be
done
for
the
uxkr
on
release
evidence
still
going.
So
if
you
want
to
leave
some
feedback
or
take
a
look,
the
link
is
there.
C
All
right,
so
I
guess
I'll
go
next,
so
I'm
currently
working
on
documenting
the
conceptual
object
model
for
jobs,
so
you'll
see
that
I
linked
figma
here
right
now,
I'm
in
the
process
of
just
mapping
out
all
of
the
job
attributes
and
actions
and
the
different
relationships
between
other
objects.
C
It's
my
first
time
attempting
something
like
this
for
such
a
complex
product
like
gitlab.
So
it
would
be
great
if
you
could
have
a
look
and
see
if
you
see
any
gaps,
any
missing
relationships
or
attributes
or
actions,
and
I
will
be
making
nmr
to
add
this
to
pajamas
soon
and
there
will
be
some
collaboration
on
nmr.
C
I
haven't
shared
it
with
the
foundations
team
yet
and
you'll
see
that
there's
also
a
discussion
around
how
to
document
objects
in
pajamas
that
pedro
started.
So
currently
we
don't
have
any
guidelines
around
how
this
should
be
documented
in
pajamas.
C
We
did
this
exercise
a
while
back
for
documenting
the
merge
request
as
an
object,
but
it
was
like
one
of
thing
and
since
then
we
haven't
really
repeated
that
process
and
yeah.
There's
a
discussion
around
how
we
should
do
this.
What
the
guidelines
should
be,
and
the
intention
is
to
create
a
set
of
contribution
guidelines,
so
other
designers
can
work
on
this,
because
creating
this
map
for
whole
gitlab
will
definitely
have
to
be
like
a
shared
effort
by
different
designers.
C
So
yeah
feel
free
to
comment
on
figma
when
you
have
a
chance,
if
you
think
any
of
the
relationships
are
incorrect
or
if
anything
is
missing
yeah,
and
I
will
also
ping
you
on
the
mr
once
it's
ready.
C
And
another
issue
yeah
daniel,
so
I
will.
I
will
have
a
look
at
your
mr
for
environments.
D
Yeah,
sorry,
I
was
typing
my
comment,
but
I
think
it's
better
if
I
voice
it
first,
this
is
really
great
nadia
thanks
for
sharing,
I'm
not
sure
if
the
figma
file
might
be
the
better
place
for
this,
but
I
wonder
if
we
can
have
two
things:
first,
a
small
definition
of
what
the
object
is
like
just
a
small
paragraph.
D
So
if
someone
has
no
context
or
very
little
context
of
what
a
job
is
to
to
prime
them
a
little
bit
before
they
get
to
this
graph,
where,
like
here,
it
shows
all
the
little
pieces
of
what
a
job
is.
But
if
you
have
no
idea
what
it
is,
then
maybe
these
little
pieces
pieces
don't
add
up
to
the
to
the
hole.
If
you
know
what
I
mean.
D
D
That
is
one
idea
and
the
other
idea
which
I'm
I'm
not
even
sure
if
it's
possible,
like
all
of
these
point
to
other
things
right,
so
the
job
points
to
an
environment,
for
example.
I
wonder
if
you
could
link
these
conceptual
models
together.
D
So
if
I
click
on
from
from
the
job
graph
into
environment,
I
go
into
the
environment,
object
model
and
then
from
there.
If
the
environment
has
a
merge
request
attached,
I
can
click
on
the
merge
request
and
then
go
to
the
merge
request.
Object
to
you
know
if
you're
exploring
these
objects
to
try
to
understand
like
the
information
architecture
behind
that
lab,
then
you
can
literally
navigate
between
them,
that
that
could
be
something
that
is
interesting
to
have.
C
Yeah,
I
think
it's
a
great
idea
check
out
this
issue
that
I
linked
where
the
discussion
is
happening.
These
are
exactly
the
things
that
we're
discussing
there.
So
how
should
be
documented?
What
information
should
we
include?
Because
if
you
have
a
look
at
how
the
merge
request
is
documented
as
an
object?
We
don't
really
talk
in
that
page
about
the
merger
quest
that
much.
C
A
Nadia
my,
I
also
have
a
thought
on
that
how
the
foundation
teams
did
with
the
with
the
merger
class
writing
as
an
object
and
also
with
the
whole
framework,
is
that
they
kept
everything
in
figma
and
once
all
the
drives
or
everyone
that
was
involved
right,
use
the
comment,
sections
and
everything
that
information
was
done.
They
migrated
to
pajamas
so
keep
that
in
figma.
For
now,
I
think
what
then
you're
suggesting
might
create
more
back
and
forth
for
you
emerge
requests
and
then
going
back
to
figma
and
issues.
A
So
if
you
have,
you
know
your
framework
with
the
information
that
daniel
suggested
about
what
is
what
is
a
pipeline?
What
is
a
job,
etc,
and
once
you
get
that
move
to
two
pajamas,
because
you
know
how
the
process
it
is
to
get
something
approval,
approved
and
merged
into
pajamas
that
might
take
longer
than
expected,
and
in
figma
you
have
control
of
that
working
progress.
So
keep
that
centralized
in
figma.
C
Yeah
makes
sense,
yeah,
that's
the
plan,
so
currently,
what
I'm
doing
is
I'm
working
on
figma
and
I'm
getting
some
feedback
on
what
I'm
documenting
in
figma
and
I'm
also
participating
in
the
discussions
with
the
foundations
team
in
this
issue
that
I
linked
around
how
we
should
document
this,
because
now
there's
lots
of
like
ideas
up
in
the
air.
So
I
think
once
we're
able
to
narrow
down
to
at
least
some
kind
of
mvc
guideline,
then
I
will
be
making
mmr
based
on
that.
C
And
another
issue
I
have
hold
on,
I
lost
a
link
to
it.
I
forgot
to
edit.
C
So
this
issue
proposes
adding
another
retry
action
to
trigger
jobs,
so
trigger
jobs
are
jobs
that
trigger
downstream
pipelines.
So
you
can
set
a
job
to
trigger
a
downstream
pipeline
and
then
that
downstream
pipeline
in
return
might
trigger
another
downstream
pipeline.
So
in
large
organizations
that
have
complex
pipeline
setups,
it's
not
uncommon
to
see
a
situation
where
you
have
a
trigger
job
that
triggers
like
tens
of
downstream
pipelines
where
each
pipeline
triggers
the
next
one,
which
makes
it
very
difficult.
C
Then,
if
there's
some
failed
jobs
in
those
downstream
pipelines
to
retry
them,
so
you
would
have
to
navigate
to
each
of
those
downstream
pipelines
and
you
would
have
to
either
retry
the
whole
downstream
pipeline
or
you
have
to
actually
go
look
for
those
failed
jobs
and
click
on
on
retry
buttons,
one
by
one.
So
that
is
just
time
consuming
and
if
you
want
to
try
all
of
the
downstream
pipelines,
it's
also
not
very
cost
effective
because
you
don't
want
to
be
rerunning
all
of
your
pipelines.
C
If
you
only
want
to
retry
some
of
the
failed
jobs,
so
the
need
for
those
customers
is
to
have
a
way
to
retry
the
failed
jobs
in
all
of
those
pipelines
from
one
centralized
place,
and
the
idea
is
to
add
the
section
to
the
trigger
job
in
the
job
page,
initially
we're
thinking
of
adding
it
to
the
pipeline
graph.
But
there's
been
multiple
complications
with
that,
starting
from
a
complexity
of
implementation
and
generally
it
wouldn't
fit
everyone's
workflow.
C
So
not
everyone
uses
the
the
main
pipeline
graph
to
to
do
those
actions
and
also,
if
you
are
investigating
a
job
that
triggers
downstream
pipelines-
and
there
are
some
problems
there-
you
will
likely
open
the
trigger
job
and
have
a
look
at
the
logs.
So
you
will
already
be
in
that
place
where
you
can
take
that
action.
C
A
Nadia,
I
have
a
question
slash
request:
can
you
just
quickly
explain
what
a
downstream
pipeline
is
for
those
that
are
not
familiar
with.
C
The
concept
I'm
also
trying
to
pull
up
a
handbook
page
or
a
docs
page,
so
a
downstream
pipeline
is
a
pipeline
that
it's
it's
like
a
separate
pipeline,
triggered
by
your
main
pipeline.
So
another
way
to
name
it
is
it's
a
child
pipeline,
so
you
have
the
parent
pipeline
that
is
defined
by
the
gitlab
ci.dml
file
in
your
project.
That's
your
main
pipeline
configuration
and
then
you
can
set
up
some
of
the
jobs
in
your
main
pipeline
that
are
called
trigger
jobs
to
trigger
those
child
pipelines
and
those
child
pipelines
run
separately.
C
So
if
you
have
a
very
complex
setup
and
you
need
to
run
a
bunch
of
different
operations
all
at
once,
it's
an
easy
way
to
kind
of
separate
different
tasks
into
like
a
different
container.
It
just
runs
separately
from
it.
A
downstream
pipeline
can
even
be
a
pipeline
in
a
different
project,
so
you
can
have
a
trigger
job
that
triggers
a
child
pipeline
inside
your
project
or
it
can
be
a
pipeline
in
a
different
project
which
is
a
multi-project
pipeline.
C
So
we
have
this
concept
of
downstream
pipelines
and
inside
we
have
your
child
pipeline,
which
is
inside
your
own
project.
So
it
means
the
file
is
in
your
project,
repo
for
that
pipeline,
and
we
have
multi-project
pipelines,
which
is
a
pipeline
defined
by
a
yaml
file
in
a
different
project,
but
both
of
these
are
called
downstream
pipelines.
A
It
thanks
nadia
for
the
video
review
and
before
I
finish
typing
my
comments,
I
think
that's
that's.
It
really
exemplifies
why
it's
so
important
for
us
to
achieve
that
higher
level
not
only
overview,
but
management
of
an
application
right
when
you
say
specifically
when
you
say
a
downstream
pipeline,
is
something
that
triggers
an
action
in
a
different
project
or
in
a
different
group.
That's
what
we
don't
have
today
and
in
context
of
what
daniel
was
explaining
before
deployments
and
environments,
is
that
everything
is
scattered,
but
usually
our
cicd
personas.
A
D
Yes,
so
I'm
gonna,
I
was
gonna,
ask
something
that
you
already
confirmed
if
the
downstream
pipelines
can
also
be
in
the
same
project,
but
in
that
case,
how
does
it
work?
Does
a
project
has
multiple
yml
files
with
different
names,
how's
that
set
up.
C
Yeah,
so
yaml
files
can
have
any
names,
and
if
you
have
a
look
at
a
gitlab
pipeline,
we
have
a
bunch
of
yml
files
that
define
the
pipeline.
C
So
generally,
you
would
have
your
main
configuration
file
by
default.
It's
called
gitlabci.yaml,
but
you
can
also
give
it
a
custom
name
and
you,
and
it's
quite
common-
to
break
up
your
pipeline
into
a
bunch
of
other
files
that
you
either
include
in
your
pipeline,
using
the
include
keyword,
which
kind
of
just
injects
that
that
other
yaml
file
into
your
main
pipeline.
So
when
the
pipeline
runs
it's
as
if
it
was
all
in
one
file,
but
downstream
pipelines
are
a
bit
different.
C
So
when
you
use
the
trigger
keyword
in
a
job
which
turns
this
job
into
a
trigger
job
and
it
looks
something
like
trigger
and
a
file
name
or
like
a
path
to
the
yaml
file
and
that
will
trigger
either
this
this
other
pipeline
as
a
child
pipeline
if
it's
in
the
same
project.
So
it's
just
it's
just
a
yaml
file
in
your
repo,
just
like
your
main
pipeline
or
it's
going
to
be
a
multi-project
pipeline.
If
it's
a
path
to
a
different
project,.
D
D
I
think
hyuna's
question
already
went
right
talking
about
why
it's
important
to
have
a
high
level
yeah
right.
So
my
other
question
is
about
the
actual
button,
the
actual
mock-up.
So
so
here
the
copy
says
retry
the
trigger
job
on
the
first
option,
which
is
the
option
we
have
today,
I
assume
and
then
the
secondary
one,
that's
being
added
by
the
drop
down.
D
Is
we
try
the
failed
jobs
in
the
downstream
pipelines,
but
then
the
the
difference
between
the
two
is
that
the
first
one
retries
all
the
jobs
in
the
downstream
pipelines,
all
the
second
one,
only
retries
the
failed
jobs
is
that
it.
C
So
actually,
currently
trigger
jobs,
don't
have
any
retry
button
and
that's
that
was
kind
of
by
design,
because
we
we
didn't
want
users
to
like
some.
Some
organizations
don't
want
developers
to
be
retrying
the
trigger
jobs,
because
that
can
trigger
all
of
those
cascading
pipelines
to
rerun,
which
can
be
quite
costly,
but
we've
been
getting
requests
to
have
that
option
still,
because
not
everyone
has
such
a
complex
setup
and
we
need
to
have
consistent
actions
on
all
jobs.
So,
regardless,
if
it's
trigger
job
or
a
regular
job,
there
should
be
a
retry
button.
C
So
that's
the
first
thing
and
here's
a
link
for
that
issue
so
issue
for
adding
a
try
button.
C
To
trigger
jobs,
and
then
that
will
solve
a
problem
where
you
want
to
retry
your
whole
or
rerun
your
whole
downstream
pipeline.
So
what
happens
is
when
you
retry
a
job?
It
reruns
every
the
script
in
the
job
and
if
it
triggers
a
downstream
pipeline,
it
means
it
will
rerun
the
whole
dungeon
pipeline.
It
will
recreate
a
pipeline
which
is
necessary
for
some
use
cases
when,
when
you
you,
you
have
that
pipeline
consuming
some
artifacts
or
like
something
needs
to
be
regenerated
in
that
pipeline
for
it
to
work
so
retrying.
C
The
failed
jobs
in
that
pipeline
is
not
really
enough.
Another
nuance
here
is
that
when
you
open
the
pipeline
page
and
if
a
pipeline
fails,
you
will
have
the
retry
button,
it
says
retry,
but
it
actually
only
retries
the
failed
jobs
in
that
pipeline,
and
that
is
the
default
behavior
and
I
was
actually
not
aware
of
it
until
quite
recently.
C
It's
not
really
well
documented
and
from
the
ui,
it's
not
really
obvious,
but
we
haven't
really
gotten
complaints
from
our
users
about
it.
So
I
don't
know.
Maybe
it's
not
a
problem,
but
basically
that's
why
we're
retrying
a
downstream
pipeline
will
not
really
solve
the
problem.
When
you
need
to
regenerate
something
in
that
pipeline,
because
it's
only
going
to
retry
the
failed
jobs,
it's
not
going
to
rerun
certain
jobs
that
maybe
need
to
generate
some
artifacts
for
things
to
work.
C
So
that's
why
we
want
to
add
the
retry
button
to
a
trigger
job,
to
make
it
possible
for
you
to
do
that
without
clicking
into
the
downstream
pipeline,
because
that
way
you
can
retry
the
trigger
job
and
it
will
rerun
the
whole
downstream
pipeline,
but
there's
also
this
very
special
use
case
for
large
organizations
that
have
multiple
cascading
downstream
pipelines
and
they
want
to
retry
the
failed
jobs
in
all
of
those
downstream
pipelines.
C
So
if
you
click
on
an
individual
downstream
pipeline
and
click
retry
there,
it
will
retry
the
failed
jobs
only
in
that
pipeline,
it's
not
going
to
retry
the
failed
jobs
in
any
downstream
pipelines
that
may
be
triggered
by
that
downstream
pipeline.
It
gets
quite
complex
like
it's
it's
kind
of
like
waterfall.
C
C
Yeah,
so
the
first
option
is
just
a
basic
retry
action
that
works
just
like
for
any
other
job,
so
it's
just
going
to
rerun
the
job
and
whatever
happens
whatever
scripts
you
have
in
that
job
is
going
to
rerun
it
in
case
of
a
trigger
job.
It's
going
to
re-trigger
the
downstream
pipeline,
which
recreates
the
downstream
pipeline
and
the
second
action
yeah
it's
going
to
retry
fail
jobs
in
whatever
downstream
pipelines
that
that
trigger
job
triggers.
Basically,
so
it's
a
way
to
save
you
time,
just
retry
the
failed
jobs
from
a
single
place.
C
I'm
still
talking
to
to
jackie
about
some
complications
there
regarding
the
permissions.
So
we
need
to
figure
out
how
it's
going
to
work
when,
like
the
developer,
may
not
have
access
to
some
of
those
downstream
pipelines.
So
it
gets
quite
complex,
but
we
need
to
figure
out
how
to
surface
that
information
in
case
there's
no
permission
to
retry
some
of
those
jobs,
but
otherwise
that
should
solve
that
problem.
D
Right
that
makes
sense
thanks
for
the
explanation.
One
last
point
you
mentioned
permissions:
you
might
want
to
to
keep
an
eye
out
for
permissions
from
the
perspective
of
cost
control
right,
maybe
a
large
organization
where
re-tries
would
be
very
costly
once
only
some
people
to
be
able
to
retry
otherwise,
like
costs
can
get
out
of
hand.
So
that's
another
idea.
I'm
marked
to
to
follow
the
thread
as
well.
So
if
anything
else
comes
up,
I
can
also
leave
feedback,
but
thanks
for
the
overview.
A
Awesome
awesome
discussion,
very
technical,
but
I'm
glad
that
we're
having
this
face-to-face
awesome-
gina
is
not
here
today,
so
I'm
gonna
just
voice
her
point,
she's
working
on
improving
the
navigation
of
runner,
actually
making
a
consistent.
So
there
are
some
changes
happening
at
the
project
and
group
level
and
she
wants
to
cascade
this
to
the
admin
view
of
runner.
A
I
know
that
she
already
pinged
all
of
you,
but
you
have,
if
you
haven't
given
her
feedback
yet
telling
if
this
change
impacts
your
product
area
right
also
in
the
admin
view
things
reply
to
that
and
also
gina
is
doing
job
to
be
done,
interviews
to
define
the
job
to
be
done
for
usability
testing,
but
she
still
needs
to
interview
at
least
one
engineer
in
test.
So
if
you
know
someone
in
your
groups
test
engineer
key
way
that
gina
can
interview
to
talk
about
this
particular
topic
of
usability
testing.
A
A
Okay,
if
you
do
let
gina
know
and
she's,
also
working
on
improving
the
location
of
runner
registrations
for
tokens,
so
started
working
on
the
design
issues
and
discussing
technical
constraints
with
miguel.
Her
front-end
development
developer
to
separate
the
page
runner
has
a
lot
of
small
usability
improvements
that
need
to
be
addressed
and
that's
where
gina
is
spending
most
of
her
time
today,
figuring
out
how
to
align
things
and
how
to
improve
the
patterns,
improve
navigation
discoverability.
A
So
if
you're
also
looking
into
this
topics,
reach
out
to
her
because
yeah,
she
also
needs
to
get
the
context
of
how
the
personas
consume
the
data
right
for
ci
cd.
So
let
her
know
nvidia
is
not
here
because
awesome
pto
for
the
next
few
weeks.
Here's
the
link
here
the
coverage
issue.
I
think
some
of
us
are
covering
for
her
backups
for
merge
requests,
also
check-ins
on
research
and
validation.
A
A
I
know
vitica
is
working
on
so
the
first
one
we
mentioned
a
couple
of
times
the
redesign
right
off
the
table
or
the
investigation
for
the
the
tabular
visual
component
and
how
to
call
that
and
the
other
one
that
she
has
been
working
with
pedro
is
simplified
strategies
with
auto
merge.
That's
also
changes
to
the
merge
request.
A
Yeah
so
have
a
look,
and
we
are
at
time
goodness
I'll
have
a
question
here
about
how
these
meetings
are
helping
you,
if
there's
anything
that
you
would
like
to
change
or
updating
the
format
feel
free
to
answer
async
so
that
we
can
always
keep
these
conversations
productive.
So
any
feedback
is
appreciated.
Awesome
all
right
anything
else.
Before
we
close
right,
then
I'll
see
you
later
thanks
for
joining
bye.
Everyone
bye.