►
From YouTube: GitLab 14.4 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
Let
me
share
my
skin
and,
as
always,
we
do
have
a
planning
issue
underneath
the
pipeline
authoring
project
issue
number
26,
where
you
can
see
all
the
issues
that
are
assigned
to
this
iteration,
we
can
ask
questions
and
collaborate
on
topics
that
are
related
to
the
planning
on
14.4
and
to
start
with
the
goals
of
this
milestone,
similar
to
the
previous
milestone.
We
are
going
to
focus
mainly
on
technical
debt,
bulk
and
performance,
because
we
want
to
improve
sas,
reliability
and
overall
reliability
of
the
products.
A
A
So
in
this
issue
we
want
to
parallelize
the
hdp
cause
of
remote
includes
and
because
it
seems
like
it
simply,
we've
been
noticing
that
there
is
some
time
out
and
and
when
doing
a
validation
of
the
lintel.
When
there
are
many
many
includes.
So
the
idea
is
to
parallelize
those
scores
and
that
way
we
can
improve
the
overall
performance,
but
we
can
also
fix
maybe
provide
some
sort
of
a
fix
to
users
that
are
using
are
included
in
high
scale.
A
So
there
is
a
kind
of
an
old
issue
that
the
lintel
is
timed
out,
because
when
users
are
using
more
than
50
includes,
so
you
can
imagine,
probably
like
large
customers
that
are
doing
that.
There
are
a
lot
of
tickets
and
we
kind
of
suspect
that
this
problem,
probably
get
resolved,
will
get
better
if
we
will
fix
this
technical
depth
that
we
have.
A
So
I
think
this
is
one
of
those
examples
where
you
can
one
complete
the
technical
depth
issue
fix
the
technical
depth
and
also
by
doing
that,
improving
the
user
experience
of
one
of
the
key
problems
that
we
experience
in
the
product
and
and
of
course
there
are
more
issues
like
that
and
two
malicious
that
I
want
to
call
out
from
the
front
end,
and
one
of
them
is
adding
the
pipeline
mini
graph
to
the
pipeline
editor.
A
Page
we'll
be
noticing
that
a
lot
of
our
engineers
and
engineers
that
we've
been
interviewing,
I
like
to
interact
with
the
piper
mini
graph,
because
it
provide
them
with
an
easy
way
to
first
understand
how
the
pipeline
looks
and
quickly
navigate
to
a
specific
job
that
they
want
to
look
at,
and
this
is
why
we
believe
that
this
is
a
good
improvement
for
the
pipeline
editor
and
the
second
one
is
the
auto
completion
of
a
ci
keyword.
A
If
you
remember
in
the
previous
iteration
and
actually
in
this
situation,
we
are
currently
working
on
building
the
foundation
for
the
syntax,
highlighting
and
autocomplete.
So
I
really
hope
that
we'll
be
able
to
complete
this
issue
on
on
time
and
then
we'll
be
able
to
start
working
on
improving
the
autocomplete
of
of
ci
keyword
and
the
ideas
will
have
the
ability
for
the
user
that
used
the
pipeline
editor
to
suggest
all
the
available
keyword
and
suggest
the
available
keyword
based
on
the
right
value.
A
So
not
only
have
those
value,
but
also
the
right
values
for,
for
instance,
when
I
type
when
colon
space
I'll
be
able
to
see
all
the
options
that
comes
with
the
keyword
when
and
if
you've
been
using
the
python
editor,
you
maybe
stumble
upon
the
autocomplete
capability.
It
is
it
exists,
but
it's
it's.
It's
a
bit
buggy
and
doesn't
work
all
the
time
and
in
this
issue
we
want
to
make
sure
we
are
fixing
it.
So
it
will
be
available.
We
kind
of
realized
that
it
is
only
working
when
you
hitting
the
space
key.
A
So
there
are
some
problems
there.
So
the
idea
here
is
to
fix
the
autocomplete,
so
we'll
have
like
something
that
we
can
work
on
and,
as
I
mentioned,
it
is
a
part
of
the
overall
auto
complete
epic,
where
the
idea
is
not
to
have
only
the
auto
suggestion,
but
also
to
have
some
sort
of
a
description
and
then
a
link
to
our
documentation.
A
Obviously,
we
need
to
flesh
out
the
design,
but
this
is
the
first
step
that
we
are
doing
towards
working
on
and
adding
the
autocomplete
functionality
to
the
pipeline
editor
and
with
that
said,
I'm
going
to
hand
it
over
to
nadia
and
she's
going
to
talk
about
the
scope
of
work
for
this
duration.
Take
it
away
nadia.
B
One
of
them
is
that
we
want
to
surface
the
links
to
the
ci
cd
configuration
includes
in
your
gitlab
ci
yaml
file
in
the
pipeline
editor.
So
we
had
a
spike
issue,
exploring
how
we
might
do
that.
Initially,
we
wanted
to
make
the
includes
clickable
in
the
file
that
is
proving
to
be
a
bit
difficult.
Technically,
we
might
still
look
into
doing
that
in
the
future
in
some
way,
but
for
now
we
want
to
surface
those
links.
B
So
all
of
the
links
to
your
configuration
includes
in
the
pipeline
editor.
So
I
will
be
working
on
this
design
issue
to
figure
out
what
is
going
to
look
like
inside
the
pipeline
editor,
and
we
view
it
as
sort
of
one
step
in
the
direction
of
having
a
way
for
you
to
navigate
between
all
of
your
different
configuration
files
inside
the
pipeline
editor.
So
eventually,
this
might
grow
into
something
like
having
a
multifile
editor
similar
to
what
you
would
have
in
web
id.
B
But
for
now
we
just
want
to
start
with
providing
a
list
of
links
to
all
of
your
includes,
so
you
would
be
able
to
view
them
in
one
place.
So
that's
one
issue.
Another
issue
that
I
will
be
working
on
is
solution,
validation
for
adding
a
pipeline
creation
simulation
to
the
pipeline
editor.
So
this
is
the
design
issue
that
I
worked
on
in
the
previous
milestone,
and
the
idea
here
is
that
we
want
to
allow
you
to
simulate
pipeline
creation
for
the
selected
branch
in
the
pipeline
editor.
B
Currently,
the
pipeline
editor
already
has
linting
so
continuous
linting
as
you're
typing
your
configuration,
but
it
only
does
the
syntax
checks,
so
it
doesn't
really
check
your
pipeline
logic,
things
like
rules
and
job
dependencies,
and
things
like
that,
so
the
pipeline
creation
simulation
will
solve
for
that,
and
you
would
be
able
to
also
test
your
pipeline
logic
without
leaving
the
pipeline.
B
Editor,
so
I
will
be
running
some
solution:
validation,
gathering
feedback
on
it
to
see
if
we
can
improve
the
layout
or
the
ui
copy,
to
make
sure
that
everything
is
clear
and
easy
to
use
the.
So
I
opened
the
same
issue,
so
the
other
two
issues
are
also
very
exciting
and
have
a
lot
of
upvotes,
so
one
of
them
is
to
allow
you
to
retry
manual
jobs
with
different
variables.
So,
as
you
can
see,
the
issue
has
more
than
100
upvotes.
B
So
for
this
particular
issue
there
are
two
main
problems.
One
problem
is
that
currently,
when
you
retry
a
manual
job,
that's
been
that's
that
has
some
some
custom
variables
set
up
for
it.
We
don't
inherit
those
variables
during
a
retry,
so
we
will
fix
that.
So
if
you
run
a
manual
job
with
custom
variables,
we
will
make
sure
to
use
those
variables
when
we
retry
those
jobs.
So
that's
part
of
the
proposal.
B
Another
part
of
proposal
is
to
take
it
a
step
further
and
to
allow
you
to
override
those
variables
and
to
set
variables
for
retrying
your
job.
So
if
you
want
to
troubleshoot
your
job,
you
want
to
try
it
with
different
variables.
You
will
be
able
to
do
so,
and
we
have
some
preliminary
mock-ups
for
that,
and
I
will
be
running
solution
validation
to
see
if
this
can
further
be
improved.
B
So
for
now
we're
just
looking
at
this
within
the
scope
of
manual
jobs,
but
this
feature
could
also
be
very
useful
for
any
jobs
in
your
pipeline,
so
we'll
be
looking
into
that
as
well,
and
the
last
one
that
I
want
to
cover
is
allowing
you
to
retry
the
failed
jobs
in
the
downstream
pipelines.
So
this
is
a
very
interesting
issue
that
covers
lots
of
different
use
cases.
B
So
when
you
have
a
complex
pipeline
configuration
with
a
lot
of
downstream
pipelines
and
you
have
failed
jobs
in
some
of
your
downstream
pipelines,
there's
currently
no
easy
way
to
retry
all
of
those
scale,
jobs
from
the
pipeline
graph.
So
from
one
place
because
you
might
have
dozens
of
downstream
pipelines
and
it's
very
time
consuming
for
you
to
go
into
each
downstream
pipeline
and
to
retry
those
individuals
fail
jobs
and
the
same
time,
if
you
wanted
to
just
retry
the
whole
pipeline.
B
That's
just
very
costly,
because
now
you
have
to
run
all
of
those
downstream
pipelines
just
to
retry
some
of
those
failed
jobs.
So
we're
looking
into
different
solutions
that
could
solve
this
problem
and
there
are
several
different
approaches
that
we're
considering,
for
instance,
adding
an
option
to
retry
the
failed
jobs
to
the
trigger
jobs.
So
you
would
be
able
to
retry
the
failed
jobs
in
all
of
your
downstream
pipelines
from
the
trigger
job
and
we're
also
considering
some
things
like
adding
the
retry
button
to
a
downstream
pipeline,
for
example.
B
So
that
would
allow
you
to
retry
the
downstream
pipeline
from
the
pipeline
graph.
So
there
will
also
be
some
more
exploration
and
we
will
be
gathering
feedback
around
which
of
these
solutions
should
be
prioritized
and
and
so
on.
So
yeah.
As
you
can
see,
lots
of
really
exciting
issues
that
I
will
be
working
on
in
terms
of
ux
in
14.4,
if
you
want
to
check
out
the
other
issues
that
I
will
be
working
on,
there
will
be
lots
of
solution.
B
Validation,
for
example,
pipeline
editor
usability
testing
that
will
hopefully
help
us
uncover
some
ways
to
improve
the
pipeline.
Editor
ui
and
fix
some
minor
quirks
in
its
behavior,
so
yeah
stay
tuned
for
those
updates
and
feel
free
to
click
through
to
the
issues
in
the
planning
issue
itself.