►
From YouTube: GitLab 13.10 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
So
I
expect
that,
although
in
this
week
we
will
also
be
above
8k
users,
now
it's
important
to
say
that
this
metric
might
be
not
that
accurate,
because
we
probably
can
do
some
more
work
on
making
it
more
accurate
in
terms
of
removing
internal
usage
that
we
are
using
and
testing
and
more.
But
what
I'm
looking
here
is
actually
a
comparison.
So
I'm
comparing
the
pipeline
editor
users
to
the
users
that
briefly
previously
used
the
part,
the
gitlab
gui
to
update
or
configure
the
pipeline.
A
So
previously,
users
will
be
able
were
able
to
update
their
pipeline
using
the
single
file
editor
or
the
web
id,
and
we
are
capturing
like
users
that
are
editing
the
pipeline
file
on
master
using
the
web,
the
the
single
file
editor
and
not
on
master,
like
master
plus
any
any
other
branch
and
number
of
users
that
are
using
that
are
updating
the
pipeline
using
the
web
id.
A
And
you
can
see
that
with
a
single
file
editor,
we
had
like
on
2.5
k,
almost
double
the
amount
of
users
that
are
using
that
are
editing
it
on
non-master
or
master
plus
any
other
branch
and
less
than
1
000
users
that
using
the
web
id.
And
if
we
look
at
the
pipeline
editor
and
I'm
using
the
same
query,
I'm
just
changing
the
url.
A
You
can
see
that
we
have
like
way
more
like
more
than
8k
users,
as
I
mentioned,
which
basically
means
that
the
pipeline
editor
does
provide
value
on
top
of
what
we
previously
had
and
like
that's,
not
surprised.
It
just
made
me
happy
to
see
that
and
a
lot
of
users
that
are
experiencing
this,
the
same
the
same
feeling
that
I
have,
and
so
the
idea
in
this
release.
A
A
The
pipeline
editor
works
only
on
the
main
branch
on
the
master
branch
and,
if
I'll,
just
like
look
at
the
number
of
users
that
are
using
the
single
file
editor
using
the
master
branch
versus
users
that
are
using
it
all
branches,
you
can
see
that
there
are
like
more
use
almost
like
less
than
two,
I
would
say
less
than
two
times,
but
still
you
can
see
that
there
is
like
much
more
users
that
would
like
to
probably
updating
their
pipeline
on
a
non-default
or
the
non
main
branch.
A
A
We
are
still
discussing
about
how
to
make
sure
we
will
provide
like
an
mvc
style
because,
like
there
are
this,
this
is
a
big
feature.
Just
adding
a
branch
selector
is
more
than
it.
The
job
is
much
more
than
just
oops.
I
need
to
update
this
link.
Yeah.
The
job
is
much
more
than
just
adding
this
drop
down
here.
It
means
that
you
know
all
the
tabs
needs
to
be
needs
to
be
changed
accordingly.
We
need
to
make
sure
that
we
can
commit
and
more
so.
A
There
is
more
work
for
us
to
do
and
like
here
we
are
discussing
on
how
we
can
make
sure
we
will
provide
our
user
with
like
a
really
nvc
and
maybe
the
rest
of
finalize
the
feature
on
the
next
iteration.
So
we
are
still
discussing
this,
but
this
is
definitely
something
that
we
will
work
on
in
this
coming
iteration.
A
So
today,
when
you
go
into
the
pipeline
editor
like
first
time
user,
if
you
don't
have
the
git
ci
yml
file,
you'll
get
an
error
message,
tell
you
hey,
create
a
gitlab,
ci,
amplifier
and
then
come
back
to
the
pipeline
editor
and
that's
not
like
the
best
user
experience
and
like
we
want
to
make
sure
that
we
keep
the
user
within
the
pipeline
editor.
We
want
to
make
sure
we
keep
them
within
the
experience
of
the
natural
flow
of
of
the
way
you
you
work
with
with
editors,
and
usually
you
start
with
an
editor.
A
You
continue
to
work
on
the
editor
and
and
this
experience
that
we
have
today,
you
need
to
maybe
navigate
away
from
the
pipeline
or
maybe
use
your
own
editor
to
push
that
file,
and
then
we
expect
you
to
come
back.
I'm
pretty
sure
that
we
are
losing
a
lot
of
users
by
telling
them
hey
sorry,
come
back
again
style
of
message,
so
the
the
idea
here
is
to
provide
the
user
with
a
simple
call
to
action
button.
A
A
And
we
will
create
this
file,
this
file
for
you
and
then
you
can
start
commit
and
work.
So,
as
I
mentioned,
the
idea
is
to
make
sure
to
make
sure
the
experience
is
naturally
for
the
users
you
go,
you
can
start
working
from
day
one
on
the
pipeline
editor
and
the
third
issue
is
to
allow
user
to
navigate
to
the
pipeline
editor
from
the
from
the
file
viewer.
A
A
A
A
So
basically
the
the
initiative
starts,
since
there
was
a
lot
of
work
that
we
wanted
to
do
on
the
pipeline
view.
Mainly,
it
started
as
a
we
wanted
to
to
present
the
dog
or
the
need
view
on
the
pipeline
view.
So
those
are
like
two
types
of
views
that
our
users
would
like
to
see.
One
based
on
stage
stages
and
one
based
on
needs.
A
The
idea
from
the
user
is
the
user
want
us
to
take
some
of
the
feedback
that
we've
captured
through
the
the
dog
view
and
implement
it
into
the
pipeline
view?
And
in
order
to
do
this
change?
That's
a
that's
a
that's,
a
drastic
change
that
we
are
going
to
introduce
and
we
first
need
to
update
the
technology,
because
the
way
it
used
to
work
it
would
be
practically
impossible.
It
would
be
would
be
very
hard
to
work
on
this
view.
A
So,
as
I
mentioned
with
the
three
iteration,
we've
worked
on
like
refactoring
and
switching
to
graphql,
and
the
idea
is
that
in
this
iteration
we
will
we
will
roll
out
this
feature.
I
have
to
say
that,
like
once,
we
roll
out
this
feature.
As
I
mentioned,
there
are
a
lot
of
work
that
will
unlock
us
a
lot
of
possibilities
in
terms
of
how
to
improve
the
pipeline
view.
A
A
A
The
next
one
is
to
improve
the
pipe
and
edit
to
the
next
goal,
a
pipeline,
editor
user
experience.
A
one
issue
is
actually
carryable
from
the
previous
issue,
previous
iteration,
sorry,
which
is
to
provide
a
status
feedback
in
your
pipeline
editor.
So
the
minute
you
hit
the
commit-
and
you
run
the
pipeline-
you
want
to
provide
the
user
with
some
feedback.
Your
pipeline
is
running,
and
so
this
widget
over
here
will
provide
the
status
of
the
current
to
call
pipeline
if
it's
running,
if
it's
blocked,
fail
or
succeed,.
A
Is
the
auto
scroll,
so
we've
received
some
feedback
on
the
pipeline.
Editor
is
that
when
you
hit
the
the
commit
changes,
we
will
present
you
with
the
with
the
message
that
your
changes
have
been
successfully
committed.
The
problem
is
that
this
message
is
at
the
top
of
the
page,
and
usually
this
is
what
users
are
seeing
they
scroll
down
to
hit
the
commit
button.
They
don't
see
the
the
message
and
what
happened?
They
will
probably
hit
it
again
and
again
until
they
will
realize.
A
Oh
okay,
my
chances
have
been
commit,
but,
like
every
click
here
actually
is
doing
a
commit
and
rely
on
the
pipeline
rerun
the
pipeline
over
and
over
again.
So
this
issue
simply
provide
you
with
some
feedback.
You
click
on
the
commit
changes,
it
will
auto
scroll
up
and
you
will
see
this
this
message.
This
is
the
way
it
is
working
today
in
the
single
file
editor
and
we
just
like
copy
the
same
behavior.
A
A
What
happened
here
is
that,
basically,
when
there
is
a
manual
job
in
any
pipeline,
a
manual
job
is
by
default
and
allow
failure
set
to
true,
which
means
that
if
the
job
is
allowed
to
fail,
the
job
is
skipped
because,
like
the
pipeline
result,
doesn't
care
about
the
result
of
that
specific
job.
If
it
success
succeed
or
fail,
it
will
not
contribute
to
the
to
the
status
of
the
job
and
the
job
will
get
skipped.
If
you
don't
want
to
skip
the
job,
you
can
add,
allow
failure,
force
and
gross
copies.
It
will
not.
A
It
will
not
skip
the
job,
and
the
entire
pipeline
will
wait
for
the
manual
job.
So
we
will.
We
are
allowing
the
user
to
have
this
to
have
this
flexibility,
and
this
is
what
users
expect.
Okay,
however,
what
happens
when
you
define
a
need
relationship
to
a
manual
job?
A
So
what
happens
today
is
that
the
entire
pipeline
is
simply
blocked.
Okay
or
it
is
in
the
state
of
created.
What
happened
is
that
this
job,
the
manual
job,
is
not
skipped,
because
there
is
a
need,
a
job
that
needs
this
job.
So
what
happened?
We
are
like
in
kind
of
a
weird
situation
that
both
of
those
jobs
are
stopped,
and
this
is
not
the
the
desired
behavior.
The
desired
behavior
is
first
of
all
this
job,
which
is
a
manual
job,
will
skip
and
because
of
this
job
that
needs
a
manual
job.
A
It
will
also
be
skipped.
That's
what
users
expect
to
see,
and
this
is
what,
after
this
amount,
this
is
what
it
will
do
and
like
we
went
and
analyzed
and
looked
throughout
this
issue
and
like
different
comments
from
our
users
and
like
you
can
see
that
this
is
a
really
popular
issue,
almost
like
145
upvote,
maybe
a
bit
more.
If
you
add
those
icons
and
it's
an
issue
that
is
open
for,
like
I
would
say
over
a
year,
and
so
it's
about
time
we'll
fix
this
problem.
A
The
reason
for
us
not
taking
our
time
and
fixing
this
problem
is
that
I
really
was.
I
was
concerned
that
this
is
a
breaking
change,
because
we
are
changing
an
existing
behavior,
but
like
after
going
through
all
the
issues
and
going
into
meeting
with
customers.
We
we've
realized
that
this
is
just
a
bug
that
we
need
to
fix.
We
will
over
communicate
this
and,
and
I
will
probably
publish
a
short
blog
that
explain
what
we
are
doing
and
why
we
are
doing
that.
A
This
is
what
the
users
really
want
and
they
like
they
don't
have
any
walk
around
and
don't
have
a
way
for
them
to
fix
this
problem,
and
so
that's
this
issue
and
another
issue
is
allow
indicating
that
a
predecessor
job
is
optional
in
doug,
and
the
idea
here
is
that
when
you
configure
a
needs
relationship
between
job,
you
can
say
that
you
need
a
job,
but
it's
optional
by
default.
It
is
not
optional,
but
you
can
add
the
flag
and
we
are
introducing.
A
A
If
it
is
not
a
part
of
the
pipeline,
it
will
not
wait
for
it.
Okay,
it
will
run
when,
when
it's
time
for
the
job
to
run
and
why?
Why
are
we
introducing
that,
mainly
because
we've
seen
that
a
lot
of
users
using
the
the
rules,
keyword
and
the
words
is-
is
a
condition
and
if
a
condition
is
is
set
for
two
or
if
the
condition
is
satisfied,
a
job
will
get
added
to
the
pipeline
and
if
not,
the
job
will
be
excluded
from
the
pipeline.
A
So
it's
a
simple
like
yes
or
no
should
we
add
this
job
to
the
pipeline
or
not,
and
this
this
is
a
problem
when
you're
using
the
needs
relationship
to
a
job
that
used
like
the
rules
keyword.
Why?
Because,
if
a
specific
job
needs
a
job
that
use
the
rules
keyword,
it
means
that
sometimes
the
job
will
get
added
to
the
pipeline,
and
then
there
will
be
no
problem.
The
pipeline
will
run,
and
sometimes
the
job
will
not
get
added
to
the
pipeline,
because
the
rule
was
set
to
false
and
what
happened.
A
They
notice
that,
like
the
pipeline,
the
pipeline,
we
don't,
we
don't
provide
any
error
and
we
don't
provide.
I
think
we
provide
now
a
warning.
Tell
them
hey
like
you,
you
have
a
needs
relationship
to
do
a
job
that,
like
using
rules
so
like
when
you
run
the
pipeline,
it
might
fail,
but
then
again
we
don't
provide
them
with
some
flexibility
of
controlling
when
it
will
fail
or
not,
and
this
is
exactly
what
this
keyword
will
allow
the
user.
A
So
if
you
need
a
job
that
use,
I
would
normally
expect
the
user
to
use
it
when
they're
using
like
the
world's
keyword,
but
maybe
there
are
more
like
maybe
in
like
when
they
want
to
run
like
on
master
or
something
like
that,
so
it
will
tell
that
this
job
is
optional
and
basically
will
not
fail
the
pipeline
if
the
job
is
not
added
to
the
pipeline
from
the
for
the
first
place,
and
you
can
see
also,
the
amount
of
upvote
is
is
pretty
high
yeah,
and
I
think
this
is
it.
A
Those
are
like
the
top
issues
that
will
be
marked
as
deliverables,
and
there
are
more
issues
here
and,
but
I
think
like,
if
we'll
have
time,
we
can
go
over.
Those
issues
like
engineers
can
work
on
those
issues,
but
I
think
those
are
like
the
the
top
of
the
critical
one
and
that
you
want
to
make
sure
are
implemented
in
this
coming
iteration,
that's
it
as
always,
if
you
have
any
questions,
feel
free
to
ping
me
or
leave
your
leave.
Your
comment
here
on
this
planning
issue.
Thank
you
and
bye.