►
From YouTube: GitLab 14.8 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
A
Each
issue
represent
an
endpoint
that
we
will
look
into,
and
I
think
that
what
we'll
do
is
that
in
each
iteration
we
will
try
to
optimize
one
to
two
end
point
until
we
will
reach
a
level
that
we
think
that
the
our
budget
is
is
good
enough
and
it
will
be
green.
So
there
is
a
lot
of
work
ahead
of
us,
but
we'll
take
it
slowly,
step
by
step.
A
The
second
thing
is
to
continue
to
walk
the
work
around
the
triggering
and
retrying
jobs
in
pipeline,
which
is
the
epic
that
we've
started.
A
couple
of
iterations
ago,
it
is
about
adding
a
retry
button
to
a
bridge
job
and
then
adding
the
ability
to
also
with
like
the
failed
job
in
a
downstream
pipeline.
So
we
are
moving
slowly
but
steadily
on
finishing
this
entire,
this
entire
epic
and
I'm
hoping
that
in
this
iteration,
we'll
be
able
to
implement
this
screen
with
this
split
button
and
yeah.
And
this
is
the
front
end.
A
A
So
user
will
be
able
to
maximize
the
the
view
of
the
pipeline,
and
it
is
very
useful
when
you
have
like
a
really
large
pipeline
and
you
want
to
use
the
the
full
extent
of
your
of
your
skin
and
and
lastly,
this
is
a
quite
popular
issue
which
I'm
really
hoping
we'll
be
able
to
to
implement,
which
is
allowing
user
to
identify
when
there
is
a
new
or
empty
branch.
A
And
first
you
can
see
that
this
is
a
quite
popular
issue
that
has
been
in
for
quite
some
time.
I
would
say,
and
was
unfortunately
weren't
able
to
proceed
with
that,
because
it
was
very
hard
to
identify
when
there
is
a
new
and
empty
blank
sheet.
Now,
why
does
user
needs
that?
So
the
way
our
pipeline
works
today
is
that
whenever
you
create
a
new
branch
and
if
you
have
a
pipeline
configuration,
your
pipeline
runs
automatically
and
some
users
actually
a
lot
of
the
users.
A
Don't
want
that
behavior,
because
they're
saying
hey
like
the
pipeline
is
empty.
There
is
no
reason
for
so
the
branch
is
empty.
When
I'm
creating
a
new
branch.
There
is
no
reason
for
the
pipeline
to
to
run,
because
you
know
it's
a
waste
of
time,
resources
and
ci
minutes,
but
then
again
there
are
some
because
this
is
an
established
behavior.
There
are
a
lot
of
users
that
already
used
to
do
that
and
already
build
the
processes
based
on
the
fact
that
new
branch
will
automatically
run
a
pipeline.
A
So
obviously,
we
weren't
able
to
change
the
default
behavior,
but
what
we
were
able
to
come
up
with-
and
there
is
a
really
long
discussion
that
is
going
on
on
this
issue-
I'm
not
going
to
show
you
that,
but
eventually
what
we,
the
proposal
that
we
thought
is
to
introduce
a
new
variable,
which
is
called
ci
branch,
commit
count,
and
this
variable
will
be.
The
value
of
the
variable
will
be
zero
when
a
new
branch
is
created.
A
So
while
doing
that,
when
we
do
that,
if
a
user
will
add
an
if
statement
to
the
workflow
and
checking
this
variable,
they
can
determine
if
they
want
pipeline
to
run
on
an
empty
batch,
which
is
the
default
behavior
and
with
using
this
rule,
they'll
be
able
to
stop
pipeline
or
not
initiate
a
pipeline
whenever
a
new
planche
is
killed
yeah.
So
I'm
hoping
hoping
this
explanation
is
understood,
but
you
can
read
through
that.
If
you
have
any
other
question,
you
can
reach
out
to
me
and
that's
it.
A
We
do
have
some
issues
for
14.7
that
might
get
case
carried
over
and
hopefully
not
a
lot.
This
is
why
I
kept
this
scope
of
walk,
quite
quite
small
and
with
that
said,
I'm
going
to
hand
it
over
to
nadia
she's,
going
to
talk
about
the
scope
of
work
for
ux.
B
All
right,
let
me
share
my
screen
so
in
14.8
we're
going
to
continue
our
focus
on
the
usability
of
pipeline
authoring
features,
and
there
are
several
design
issues
that
I
will
be
working
on.
They're
quite
interesting,
so
I
will
highlight
just
a
few
of
them.
B
So
first
we
want
to
allow
you
to
select
from
a
predefined
list
of
values
for
ci
environment
variables,
so
there's
multiple
issues
that
we
currently
have
around
surfacing
variables
in
github
ui
and
we
think
making
variables
accessible
in
the
ui
will
make
them
much
easier
to
use,
and
this
is
just
one
of
those
issues.
So
in
this
particular
case
we
want
to
surface
the
available
variable
values
in
the
pipeline
run
page.
B
B
So
when
you
go
to
the
pipeline
editor
to
create
your
python
configuration,
you
need
to
know
that
you
need
a
runner,
because,
if
you're
entirely
new
to
giveaway-
maybe
you
you
will
not
be
aware
of
this.
So
this
is
some
information
that
we
need
to
surface
in
the
pipeline
editor
and
that
would
improve
the
experience
for
new
users
of
gitlab
ci
who
use
self-managed.
B
So
I
will
be
collaborating
with
the
runner
team
on
that
with
the
router
product
designer
to
make
sure
that
we
surface
all
the
right
information
in
a
way
that
makes
the
most
sense
to
new
gitlab
ci
users,
and
there
are
also
several
issues
around
the
pipeline.
Editor
usability
improvements,
so
this
milestone
we
finished
or
last
milestone.
We
finished
ux
research
around
pipeline,
editor
usability
testing
and
we
uncovered
a
very
wide
range
of
different
improvements
that
we
could
pursue.
B
So
we're
trying
to
address
the
low
hanging
fruit
there
and
trying
to
prioritize
those
improvements.
So
two
issues
that
I
will
be
working
on
in
14.8
is
first
improving
the
behavior
of
the
pipeline
editor
drawer.
So
currently,
when
you
open
the
pipeline
editor
for
the
first
time,
we
open
the
drawer
with
some
documentation
and
onboarding
information
and
links
to
the
docs
in
the
drawer.
B
We
open
it
by
default
and
we
notice
that
this
behavior
isn't
expected
to
many
of
our
users
and
we
want
to
make
it
so
you
actually
have
to
explicitly
click
click
on
a
button
to
open
the
drawer.
It
will
align
better
with
our
design
system
guidelines
and
it
will
be
more
user-friendly
and
more
accessible
as
well,
and
another
issue
is
around
preventing
users
from
making
empty
commits
in
the
pipeline
editor.
B
So
currently
you
can
click
the
commit
button
in
the
python
editor
as
many
times
as
you
want,
and
we
don't
really
communicate
that
in
the
ui.
But
each
click
will
create
an
empty
commit
if
you
haven't
made
any
changes.
So
we
want
to
fix
that,
and
we
want
to
make
sure
that
you
can
only
make
the
commit
if
you've
made
changes
and
if
you
haven't
made
changes,
then
you
shouldn't
be
able
to
just
accidentally
create
a
bunch
of
empty
commits.
B
So
I
will
be
exploring
the
user
experience
around
that
and
there
are
some
other
issues
that
I'll
be
moving
forward.
I'm
not
gonna
get
too
much
into
those,
but
overall,
as
you
see,
our
focus
is
on
improving
the
usability
and
working
on
the
issues
that
came
out
of
ux
research.
There
are
actionable
issues,
ux
corporate
recommendations
and
so
on,
because
in
the
upcoming
quarter
we
will
be
contributing
to
the
shared
ocr
around
burning
down
all
of
those
usability
issues.
So
all
of
this
design
work
will
be
in
preparation
for
that
yeah.
That's
it.