►
From YouTube: GitLab 13.11 Kickoff - Verify:Pipeline Authoring
A
Hi
everyone-
this
is
dr
scovitz
from
the
pipeline
authoring
team.
I'm
here
joined
by
nadia
sotnikova
our
product
designer,
and
this
is
the
kickoff
video
for
version
13
11.
to
start
with.
As
always,
there
is
a
planning
issue
when
you
can
relate
to
all
the
issues
that
are
scheduled
in
this
iteration
and
to
begin
with
the
goals
of
the
milestone
goal.
Number
one
is
continue
to
work
on
the
pipeline
editor.
Second
iteration.
We
do
have
some
carryovers.
A
It
says
some
left
left
over
some
loose
ends
that
we
want
to
make
sure
we
finalize
from
a
from
previous
iteration.
A
The
second
goal
is
to
start
with
the
epic
and
show
that
relationship
in
pipeline
view,
and
the
third
goal
is
implement
some
additional
popular
customer
issues
and
bug
fixes.
I
would
call
out
one
issue
about
allow
me
to
refer
to
a
job
in
the
same
stage
and
I'm
going
to
discuss
it
soon.
A
A
So
this
issue
is
backed
up
by
some
feedback
that
we
gather
together
from
former
users
when
we
first
launched
the
the
dog
view
or
the
needs
and
the
needs
view
which
is
like
the
pipeline
and
see.
If
I
have
like
a
this
one,
and
so
we've
gathered
a
bunch
of
feedback
from
our
users
and
to
understand
if
it
indeed
solving
their
problem.
A
In
addition,
there
is
a
research
issue
that
we've
done
in
the
past
and
based
of
them,
we
reach
out
to
to
a
conclusion
that
our
users
would
like
to
see
the
needs,
relationship
and
dependencies
on
on
the
pipeline
graph.
And
this
had
this
epic
explain
exactly
what's
our
end
end
goal,
but
I'm
going
to
discuss
the
the
mvc,
so
the
mvc.
A
The
way
we
want
us
to
we
agreed
on
is
that,
first
of
all,
we
will
have
the
stage
based
view,
as
you
all
know
and
like,
but
we
won't
have
those
links
between
jobs,
the
links
that
the
links
will
arbitrary.
So
there
was
any
any
logic
between
on
on
the
links
that
we
had
in
the
past,
so
we
decided
that
we
need
to
drop
them
on
the
stage
view,
because
the
view
is
organized
by
stage
and
and
that's
it.
A
In
addition,
we
are
adding
a
drop
down,
so
the
users
will
be
able
to
toggle
between
the
stage-based
view
and
the
needs
relationship,
and
when
the
user
will
hover
over
a
job
in
the
needs
view,
they
will
be
able
to
see
the
dependencies
between
the
job
based
on
the
need
relationship
only
and
by
the
way,
this
this
description
is
not
up
to
date.
We
need
to
update
the
mvc.
We
won't
have
those
gray
lines
here.
A
A
A
First
of
all,
this
is
one
of
the
most
popular
issues
that
we
have
in
in
pipeline
authoring.
As
you
can
see,
the
number
of
upvote,
which
is
to
allow
needs
to
refer
to
to
a
job
in
the
same
in
the
same
stage.
A
Why
do
we
need
stage
at
all?
So
why
do
we
have
this
limitation
and
by
the
way,
this
is
the
way
github
action
is
working,
so
they
on
the
pipeline.
They
don't
use
stages
at
all,
they
use
just
the
needs,
they
actually
use
the
needs
keyword
and
they
only
don't
use
needs
and
speaking
with
customers,
they
claim
that
this
is
just
this
way.
A
The
pipeline
runs
faster,
I'm
not
100
sure
because,
like
a
need,
a
relationship,
a
dependency
between
stages
or
between
jobs,
it's
almost
the
same,
but
for
them
it
feels
like
there
isn't
like
the
overhead
for
creating
the
stages
is
for
when
you
offer
a
pipeline.
Why
do
we
need
stages
at
all?
Think
about
like
what,
if
I
want
to
create
a
pipeline
based
on
needs,
dependency
just
needs
with
no
stage,
and
so
you
are
unable
to
do
it
unless
we'll
implement
this
issue,
and
this
is
why
I
think
this
is
issue.
A
This
issue
is
kind
of
like
allowing
users
to
have
like
a
stageless
pipeline.
It's
not
really
stageless,
because
we
always
create
stage
by
default.
We
have
the
build
test
and
deploy
stages
by
default,
so
users
will
be
able
to
build
the
pipeline
from
one
stage
or
they
can
even
don't
write
stage
at
all
and
will
create
the
stage
for
them.
So
it's
like
kind
of
a
stageless
pipeline
and
it
is
very
related
to
the
previous
issue
here
because
think
about
it.
A
If
you
have
like
a
stageless
or
one
stage
pipeline
with
one
with
one
stage,
the
the
stage
view
will
will
be
like
a
vertical
view
and
it
won't
be
very
useful.
So
I
expect
that
users
that
will
use
the
stageless
view
will
actually
default
to
the
needs
to
the
needs
view
on
the
pipeline
yeah.
So
this
is
how
those
two
touch
points.
Yeah
and
those
are
the
two
big
items
we
are
going
to
work
on
in
the
commentation.
A
As
I
mentioned,
you
can
read
on
all
those
issues
in
the
planning
issue,
passing
it
over
to
nadia,
to
talk
about
the
scope
of
fork
for
ux,
for
this
iteration.
B
Yeah,
so
in
13.11
we
have
lots
of
very
interesting
ux
efforts
coming
up.
13.11
will
be
full
of
research
first
off
we're
starting
a
category
maturity
scorecard
for
pipeline
authoring
for
the
first
time.
So,
given
the
pipeline
authoring,
category
is
still
quite
new,
we'll
be
conducting
our
first
category.
Maturity
scorecard,
hopefully
we'll
be
able
to
move
to
bible,
we'll
see
how
it
goes
either
way.
We
will
collect
lots
of
very
interesting
feedback,
so
real
looking
forward
to
that.
B
Another
very
interesting
effort
is
continuing
our
work
on
the
visual
builder
for
the
pipeline
editor.
So
we
currently
have
an
nvc
proposal
that
you
can
check
out
in
this
epic
year,
but
we
need
to
start
exploring
how
we're
going
to
handle
actually
having
a
visual
builder.
So
how
can
we
start
adding
some
more
abstraction
to
how
you
build
and
create
your
pipelines?
B
So
we
have
explored
some
some
direction,
but
we
want
to
do
more
exploration
and
also
run
some
solution,
validation
to
gather
more
insights,
and
that
will
inform
our
further
direction
with
the
visual
builder.
So
you
can
read
more
about
our
roadmap
and
all
of
the
issues
that
we
have
planned
for
this
effort.
B
Another
interesting
effort
is
supporting
ci
job
templates,
so
this
is
very
new.
We're
just
starting
the
exploration,
but
essentially
our
goal
is
to
allow
a
central
team
that
manages
cicd
configuration
to
create
and
maintain
a
library
of
custom
templates,
whether
it's
full
csv
templates
or
job
templates.
B
We
want
to
make
sure
that
it
it
can
have
version
control
and
then
that
the
templates
can
be
easily
delivered
to
the
team,
so
they're
discoverable
for
the
team,
and
if
there
are
any
updates
to
the
templates,
the
team
will
be
able
to
opt-in
to
those
updates
and
always
have
their
templates
up
to
date.
We're
also
looking
into
providing
such
features
as
the
central
team
being
able
to
enforce
certain
templates
for
the
team,
for
example.
B
So
there's
lots
of
ideas
that
we
have
and
we're
having
discussions
in
this
issue
and
some
other
related
issues
there
are
linked
here
so
feel
free
to
check
it
out
and
another
interesting
effort
has
to
do
with
improving
cic
templates.
So
we've
recently
gone
ahead
and
created
descriptions
for
all
of
our
sexy
templates,
and
now
we
want
to
run
a
card
sorting
exercise
to
see
how
github
users
group
all
of
those
different
templates
in
a
way
that
makes
sense
to
them,
and
the
goal
here
is
to
make
the
templates
easier
to
search
and
browse.