►
From YouTube: GitLab 13.12 Kickoff - Verify:Pipeline Authoring
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
Hi
everyone,
my
name-
is
dave
hershkovitz,
the
senior
product
manager
in
gitlab,
I'm
here
joined
by
by
nadia
sutnikova
our
product
designer,
and
this
is
the
pipeline
authoring,
13.12
kickoff
video.
To
begin
with.
As
always,
we
have
a
planning
issue
where
you
can
look
at
the
entire
scope
of
this
iteration.
A
The
goals
of
this
milestone
is
first
pick
up
the
work
from
previous
iteration.
We
have
two
epics
that
we
still
need
to
work
on
the
first
one
is
add
the
brand
selector
to
the
pilot,
editor
and
just
quick
recap
today,
the
pipeline,
and
it
will
only
work
for
users
that
are
working
on
the
main
or
the
master
branch,
and
we've
been
receiving
a
lot
of
requests
from
customers
that
would
like
to
use
the
pipeline,
but
are
not
using
the
their
main
branch.
A
So
this
will
allow
those
users
to
work
on
their
pipeline
using
the
pipeline
editor.
The
second
epic
is
to
show
the
dag
relationship
in
the
pipeline
view,
which
will
allow
the
user
to
select
the
type
of
view
they
would
like
to
see
in
their
pipeline
pipeline
graph
either.
It
will
be
based
on
the
stage
based
view,
which
is
our
traditional
view
or
users
that
are
using
the
dog
or
the
need
relationship
and
have
the
dependence
they
need
dependencies
between
job.
A
The
next
big
thing
is
implementing
the
pipeline
drawer
and
the
pipeline
royal
actually
emerged
from
a
thing
big
and
things
small
session
that
we've
done
together
with
the
team,
and
the
idea
here
is
to
support
the
new
users
and
that
the
first
time
users
that
are
accessing
the
pipeline
editor
over
the
course
of
the
last
couple
of
iterations.
We
will
focus
on
bringing
a
lot
of
users
toward
the
pipeline.
Editor
establishing
the
pipeline
to
as
their
main
editor
to
author
and
update
their
pipeline.
A
This
pipeline,
basically
visual
visual
aid
to
show
how
this
pipeline
actually
looks
like
and
then
some
tips
about
how
you
visualize
and
validate
your
pipeline,
using
the
editor
and
some
resources
and
links
that
can
help
and
support
our
users
while,
while
working
on
the
pipelines,
of
course,
this
is
just
an
mvc
and
we
brainstorm
with
some
ideas
on
how
we
can
continue
walking
on
this
door,
because
this
drawer
will
allow
us
to
er
to
scale
and
maybe
add
additional
things
such
as
a
pipeline
template
in
product
integration
with
with
marketplace
or
other
repository
repository
or
more
and
but
that's
the
best.
A
A
So
today,
when
you
have
a
failed
downstream
pipeline,
one
of
the
jobs
on
the
downstream
pipeline
was
failing.
There
is
no
way
for
the
user
to
retry
the
downstream
pipeline.
The
only
work
around
is
to
rewrite
the
entire
pipeline,
and
our
nvc
approach
is
to
add
the
retry
to
the
bridge
up
and
the
red
right
to
the
bridge.
A
Job
will
only
appear
whenever
a
downstream
pipeline
is
failing,
meaning
that
at
least
one
job
out
of
this
downstream
pipeline
scale
you'll
be
able
to
see
a
retry
button
clicking
on
the
redrive
button
will
only
rewrite
the
failed
jobs
on
the
downstream
pattern.
Now,
if
your
downstream
pipeline
is
green,
we
won't
show
this
reply
button.
A
A
The
next
misdeliverable
is
the
allow
need
to
refer
to
a
job
in
the
same
stage
and
which
is
what
I
call
like
a
stageless
pipeline
to
allow
users
to
use
the
need
or
the
dag
relationship
to
a
job
within
the
within
the
same
stage.
This
will
open
the
door
for
users
to
able
to
configure
their
pipeline
configuration
without
configuring
any
stages
at
all,
and
also
here
we
may
end
up
finishing
the
work
in
13
12,
but
since
this
is
a
a
very,
this
is
a.
A
This
is
a
major
change
and
we'll
probably
take
like
a
full
iteration
to
roll
it
out.
So,
even
if
we
complete
the
the
implementation
work
in
1312,
it
will
be
released
in
in
14,
because
we
we
want
to
take
the
time
and
thoroughly
test
the
impact
of
of
this
change,
and
the
last
issue
is
a
ux
improvement
right
now.
A
So,
for
instance,
I
can
see
that
this
pipeline
was
triggered
by
test
a
job
which
is
probably
this
one,
and
this
pipeline
was
triggered
by
test
b
and
and
testy,
and
so
on
so
forth.
So
adding
this
label
will
help
users
identify
which
bridge
trigger
which
downstream
pipeline
and
we've
been
getting
a
lot
of
requirements
from
the
user
to
different
variation
on.
How
can
they
tell
which
job
trigger
which
which
pipeline
sorry
yeah?
That's
about
it
for
the
scope
of
work
for
the
deliverable
item.
B
Yeah,
let
me
share
my
screen,
hi
everyone,
so
as
we're
starting
our
work
on
the
pipeline
drawer
and
we're
continuing
our
work
on
showing
the
deck
relationships
in
the
pipeline
graph.
I
finally
have
some
time
to
do
some
proactive
work
and
do
some
high
level
design
exploration
research.
So
this
milestone
will
be
very
research
focused
for
me
with
some
design
exploration
for
like
blue
sky
vision,
and
things
like
that.
B
So
the
first
thing
that
we're
still
working
on
together
with
dove
is
our
category
maturity,
scorecard
research,
so
we're
currently
in
the
middle
of
running
the
interviews,
we're
running
interviews
with
our
internal
users,
so
we're
interviewing
gitlab
sres
as
well
as
engineers,
both
front
end
and
backhand,
to
see
how
they
do
with
the
current
experience
for
authoring
a
pipeline.
How
did
that
experience
improve?
B
Did
we
move
up
in
maturity
or
not,
and
generally
were
already
generating
lots
of
really
interesting
insights
about
how
to
further
improve
the
usability
of
the
pipeline
authoring
experience
as
well
so
very
excited
to
finish
up
this
research.
This
milestone
and
share
all
of
the
insights
with
everyone.
B
B
B
So
we
also
don't
affect
the
pipeline
graph
performance
because
the
pipeline
graph
can
be
quite
big.
It
actually
takes
a
lot
of
resources
to
draw
the
links
between
the
jobs,
so
we're
exploring
just
different
solutions
that
we
could
try
to
address
the
performance
concerns
while
delivering
the
value.
For
this
feature,
and
here
in
this
markup,
you
see
that
we
want
to
show
the
job
dependencies
between
the
jobs
and
then
you
would
be
able
to
hover
over
the
job
to
see.
B
B
So
we
will
be
testing
a
couple,
different
solutions
with
github
users
to
see
how
they
respond
and
whether
there's
a
a
preference
for
one
way
or
another
of
just
displaying
these
links.
Another
issue
I'm
very
excited
about
is
design
exploration
for
the
pipeline,
editor
ui,
and
this
issue
is
quite
broad
on
purpose.
So
the
scope
of
this
issue
is
very
broad
and
the
goal
is
to
explore
and
test
out
different
ideas
that
we've
been
discussing
for
the
evolution
of
the
pipeline,
editor
ui
for
the
visual
builder
for
the
pipeline
visualization.
B
How
can
we
bridge
the
experience
of
the
editor
and
pipeline
visualization
things
like
that,
so
we're
currently
starting
the
work
on
or
we'll
be
starting
the
work
in
13.12
on
the
pipeline
drawer,
and
that
also
creates
additional
opportunities
for
us
to
create
a
better
user
experience
in
the
pipeline
editor.
So
one
of
the
things
I'm
exploring,
for
example,
is
showing
the
templates
in
the
pipeline
drawer
like
this.
B
So
the
these
ideas
are
a
bit
far
out
for
us
like
this
is
really
kind
of
long-term
vision
exploration,
but
I
think
it's
gonna
be
great
for
us
to
create
some
mock-ups
and
to
create
those
artifacts.
So
those
ideas
that
we're
kind
of
peeing
back
and
forth,
based
on
all
of
the
research
that
we're
doing
so,
we
can
start
doing
some
solution.
B
Validation
for
those
things
as
we're
doing
customer
interviews
and
as
we're
conducting
the
category
maturity
scorecard
interviews,
so
it
just
seems
like
a
good
opportunity
to
start
testing
out
all
of
those
different
ideas.
B
So
another
little
issue
that
I
will
be
working
on
is:
how
can
we
add
a
documentation
link
to
the
keyword
description
in
the
pipeline
editor?
So
this
will
not
require
that
much
design,
but
I
think
it's
going
to
have
pretty
high
impact
on
the
usability
of
our
editor,
so
we've
just
recently
added
static
validation
to
the
pipeline
editor.
That
shows
the
additional
information
about
the
keywords
like
so
like
you
see
in
this
little
gif
and
we
want
to
also
add
documentation,
links
to
those
drop-downs.
B
So
you're
able
to
not
only
read
about
the
keyword
very
briefly,
but
if
you
want
to
dig
deeper
into
the
use
cases
and
examples
and
things
like
that,
you
can
click
on
the
documentation
link
and
it
will
take
you
to
additional
information
so
that
that
will
be
very
useful
for
anyone,
who's
new
to
gitlab's
icd,
but
really
any
user.
Because
it's
difficult
to
remember
all
of
the
syntax
and
those
are
the
major
research
and
design
efforts
that
I
will
be
working
on.
B
We
also
have
this
new
section
in
our
planning
issue
for
active
ux
research
efforts,
so
the
category
maturity
scorecard
research
dominar
running
together
the
solution,
validation
I'll,
be
running
in
139.12
as
well,
and
I
also
linked
here
the
dovetail
project
where
we
store
our
customer
interview
recordings.
That
dope
is
running,
and
sometimes
I
join
as
well.
A
Yeah,
thank
you
nadia.
So,
as
always,
if
anyone
has
any
thoughts,
questions
or
comments
feel
free
to
reach
out
to
me,
nadia
or
better
off
fingers
on
the
planning
issue.
Thanks
everyone,
bye-bye
thanks,
bye.