►
From YouTube: GitLab 14.5 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-
this
is
doug
hoskowitz,
I'm
here
with
the
nadia
sutnikova
our
ux
designer,
and
this
is
a
pipeline
authoring,
14.5
kickoff
video,
where
we
are
going
to
talk
about
the
scope
of
work
and
scope
of
ux
for
the
upcoming
iteration
and
to
begin
with.
As
always,
we
have
a
planning
issue
underneath
the
pipeline
authoring,
a
project
issue
number
27,
where
you
can
read
through
all
the
scope
of
work
that
we
have
and
plus
the
discussions
that
we
had
with
the
entire
team
when
planning
this
iteration.
A
Of
course,
you
can
add
your
thoughts
and
comments
there
as
well
and
to
begin
with
the
goals
of
the
milestone
and
we
plan
to
balance
between
bugs
and
performance
and
in
future
work.
The
reasoning
behind
that
is
that
in
the
last
couple
of
iterations,
we've
been
heavily
focusing
on
performance
improvement.
A
It
is
some
problems,
improvement
to
our
aero
budget
and
and
since
we
are
in
a
good
shape
today,
we
can
definitely
start
working
on
some
feature
work,
but
we
do
have
some
issues
that
we
want
to
close,
and
primarily
we
do
want
to
improve
even
better.
Our
error
budget
as
variables
were
moved
into
the
pipeline
authoring.
We
noticed
that
the
variable
api
does
contribute
significantly
to
the
error
budget.
A
So,
although
we
are
like
in
the
in
the
okay
zone,
we
want
to
even
be
better
in
case
you
know,
someone
will
decide
to
change
the
threshold,
so
one
of
those
issues
is
to
see
if
we
can
optimize
the
viable
api
and,
secondly,
is
a
a
follow-up
form-
a
performance
improvement
that
we've
done
to
the
a.
I
think
it
was
the
pipeline
page,
and
so
we
actually
started
in
the
previous
iteration
and
the
pipeline
page
when
there
is
a
large
number
of
high
running
number
of
jobs.
The
pipeline
plays
is
really
slow.
A
So
in
this
issue
we
were
actually
able
to
improve
significantly
the
query,
but
we
still
didn't
saw
the
impact
on
the
page
itself.
So
this
issue
is
like
to
close
this
problem
and
improve
the
the
graphql
endpoint.
So
users
would
be
actually
able
to
benefit
from
that
improvement
that
we've
made,
and
the
significance
is
not
that
significant.
A
The
way
it
is
here
too,
so
it
makes
sense
to
complete
this
work
and
and
fix
that
that
performance
issue
other
than
that
we
do
have
some
bugs
some
minor
bug
fixes
and,
as
I
mentioned,
the
next
thing
is
to
work
on
some
feature
work
and
we
do
have
some
future
work
and
that
we
wanted
to
wrap
up
as
a
part
of
the
solution.
Validation,
we've
done
in
the
pipeline
graph,
so
it
was
a
long
time
about
ago.
A
But
the
issue
that
we
are
actually
seeing
here
is
that
when
you
order
the
job
by
the
needs
dependency,
it
doesn't
take
into
consideration
the
stage
name.
So
all
the
jobs
without
any
dependency
appear
on
the
left
column.
So
it
appears
that
all
those
jobs
will
run
at
the
same
time
where
in
reality-
and
there
are
also
stages
that
need
to
get
into
consideration.
A
So
if
I
look
at
stages,
I
can
see
that
the
sync
stage
is
the
first
job
and
then
the
prepared
stage
based
on
the
job
dependency.
So
we
need
to
take
those
two
into
consideration
and
and
the
future
work
that
we
need
to
finalize
is
to
make
sure
that
when
users
are
looking
at
job
dependency,
we
will
all
the
the
jobs,
both
by
the
needs
relationship
and
by
the
sequence
of
order
based
on
the
stage
so
like.
A
In
this
view,
the
sink
need
to
be
on
the
left
column
and
after
that,
all
the
jobs
based
on
the
need
dependency
and
that's
the
work
that
we
have
for
feature.
There
is
some
package
and
some
front
and
walk,
and
hopefully
we'll
be
able
to
finalize
this
in
this
situation,
and
now
I'm
going
to
hand
it
over
to
nadya
and
nadia
is
going
to
talk
about
the
scope
of
work
for
ux.
Now
you
take
it
away.
B
Okay,
so
14.5
is
going
to
be
very
exciting
in
terms
of
ux
improvements,
so
I'll
be
focusing
on
a
handful
of
different
issues.
First,
I
will
continue
running
the
solution.
Validation
for
the
pipeline
editor
we're
currently
running
a
usability
test
to
uncover
further
improvements
in
the
pipeline
editor
to
see
if
there
are
any
bugs
that
we
need
to
fix.
We
want
to
really
polish
the
experience
in
the
pipeline
editor
we're
planning
some
further
improvements
and
features,
and
for
us
to
be
able
to
evolve
the
pipeline
editor
functionality.
B
We
also
need
to
make
sure
that
the
ui
is
very
easy
to
use
and
that
it's
really
polished.
So
we
will
be
running
the
interviews
for
that
now
in
terms
of
design.
The
issue
that
I'm
most
excited
about
is
simulating
pipeline
creation
in
the
pipeline
editor.
So
currently
we
offer
the
ability
for
you
to
simulate
pipeline
creation
in
the
standalone,
silent,
and
this
issue
is
around
moving
that
functionality
to
the
python
editor.
B
So
when
you're
working
on
your
pipeline
configuration
currently,
you
can
lint
the
the
configuration
syntax
in
the
pipeline
editor,
but
you're
not
able
to
simulate
pipeline
creation,
which
means
you
can't
really
test
any
of
the
logic
in
your
pipeline
config.
So
if
you
have
any
rules
in
your
pipeline,
you
wouldn't
be
able
to
ensure
that
it's
accurate.
So
the
simulation
will
allow
you
to
simulate
the
creation
of
a
pipeline
for
the
default
branch
and
in
the
future,
we'll
be
offering
other
execution
contacts.
B
So
we're
currently
exploring
the
designs,
and
it
might
look
a
bit
different
from
this.
But
this
is
just
to
illustrate
what
it
might
look
like.
So
we're
looking
at
creating
a
test
tab
in
the
pipeline
editor
where
you
would
be
able
to
lint
or
simulate
your
pipeline
and
at
first
it's
going
to
be
only
for
the
default
branch
commit,
but
in
the
future
it
might
be
also
a
feature
branch
commit
or
a
scheduled
pipeline.
B
B
Next,
I
will
be
working
on
our
mvc
for
the
pipeline
editor
file
tree,
which
is
also
very
very
exciting
and
as
an
mvc,
we're
looking
to
surface
a
static
list
of
links
to
all
of
your
includes
files.
B
So
when
you
have
a
pipeline
configuration
that
is
spread
over
multiple
files
and
then
you
include
all
of
those
separate
files
in
your
main
gitlab
ci
yml,
you
will
see
links
to
all
of
those
files
in
a
sidebar
or
like
a
file
tree
looking
like
section
in
the
pipeline
editor
and
you
will
be
able
to
open
those
in
a
new
tab
and
it
makes
it
easier
to
find
all
of
your
includes
files
and
navigate
to
them.
B
That
will
be
the
mvc
iteration
and
I
will
be
polishing
the
designs
further
and
running
some
solution,
validation
for
this
proposal
and
in
the
future
we
want
to
evolve
it
into
a
more
fully
featured
file
tree,
something
similar
to
the
file
tree
that
we
have
in
the
web.
Ide
and
another
exciting
issue
is
allowing
you
to
retry
manual
job
with
different
variables,
so
there
are
several
different
problems
that
we're
solving
here.
B
First,
we
want
to
surface
the
variables
that
are
used
in
manual
jobs,
and
we
also
want
to
make
it
easy
for
you
to
override
those
variables
that
are
used
by
the
manual
job
and
retry
the
job
with
different
variables.
If
you
want
to
troubleshoot
some
problems,
so
the
idea
here
is
that
we
will
be
adding
a
variables
tab
to
the
job
page
where
you
would
be
able
to
see
the
variables
that
are
being
used
and
you
would
be
able
to
override
those
variables
and
retry
the
job
with
new
variables.
B
So
this
this
can
be
a
very
powerful
feature,
making
it
much
easier
for
you
to
troubleshoot
any
problems
that
you
might
have
with
your
job,
and
this
particular
issue
focuses
on
adding
that
for
manual
jobs
only,
but
in
the
future
we
might,
we
might
consider
adding
that
for
all
jobs
as
well.
So
this
is
still
a
design
issue.
The
proposal
is
still
a
work
in
progress,
so
I
will
be
moving
this
along
and
getting
more
feedback
on
it
to
get
it
ready
for
implementation.
B
B
So
if
you
have
a
long
job
name,
the
job
name
will
be
truncated
and
in
some
cases
it
can
be
difficult
to
tell
the
jobs
apart
in
case
you,
especially
if
you
generate
the
jobs,
dynamically
and
the
names
are
generated,
dynamically
many
of
the
jobs
might
have
similar
names.
So
this
issue
is
to
explore
a
way
for
us
to
show
the
full
name
of
the
job
and
generally
to
make
the
pipeline
graph
easier
to
use
and
especially
for
a
very
large
pipeline
crafts.
B
So
yeah
as
you
can
see,
lots
of
very
exciting
work
is
happening
around
the
pipeline.
Editor
usability
the
pipeline
graph
and
some
new
features
to
help
you
validate
your
pipeline
configuration
so
yeah
very
excited
about
this
iteration.
A
Thanks
nadia,
you
did
exciting
work
for
the
ux
and
what
will
come
in
the
future
for
pipeline
authoring?
I
think
this
is
it
as
always.
If
any
of
you
have
any
questions,
comment
or
you
can
mention
me
on
the
or
nadia
or
any
of
the
members
of
the
team
on
this
planning
issue
and
thanks,
everyone
and
bye,
bye.