►
From YouTube: GitLab 14.1 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
The
playing
issue
is
located
underneath
the
pipeline
authoring
walk
issue
number
21
when
you,
you
can
read
all
about
the
content
of
this
iteration,
but
let's
go
over
the
highlights
of
this
of
this
version,
and
the
first
goal
is
to
implement
the
popular
some
of
the
most
popular
customer
requests,
and
this
is,
I
think,
by
far
the
most
popular
one,
which
is
allow
me
to
refer
to
a
job
in
the
same
stage.
I
like
to
call
this
issue
stageless
pipeline.
A
We
can
create
a
dependency
between
two
jobs
that
the
job
can
run
after
the
previous
job
is
completed,
regardless
of
the
stage
they
are
at,
and
this
is
help
our
user
to
speed
up
the
the
pipeline
by
not
considering
or
ordering
job
only
by
stages,
but
also
by
job
dependencies,
and
this
is
a
very
popular
keyword
and
very
popular
use
case
that
our
users
have
adopted
and
really
like,
but
it
has
one
one
limitation.
The
limitation
is
that
we
cannot
have
the
needs
dependency
between
jobs
that
are
on
the
same
stage.
A
So
in
this
issue
we
want
to
drop
this
limitation
and
allow
users
to
have
to
define
the
the
need
relationship
or
the
need
dependency
between
two
jobs
in
the
same
stage.
Basically,
it
will
enable
user
to
create
a
pipeline
without
a
full
full
pipeline
with
dependencies
without
stages
at
all
and
something
that
our
user
would
like
to
to
do.
A
A
The
second
issue
is
also
a
popular
issue
and
more
than
50,
upvotes
or
so
unlike
the
previous
one
but
50
upvote
is,
is
pretty
high
and
it's
pretty
simple
and
having
a
conditional
include
it's
a
simple,
it's
a
simple
requirement,
but
it
has
like
very
interesting
several
interesting
use
cases.
So
we
start
with
the
syntax.
The
syntax
is
again
it's
simple.
A
We
have
the
include
keyword
which,
with
the
include
keyword,
you
can
include
the
whole
pipeline
configuration
on
a
job,
but
we
want
to
add
the
rules,
the
rules,
keyword
or
those
conditions
and
in
if
a
specific
condition
is
met,
then
we
will
include
this
this
file
in
this
job
and
basically
it
will
help
our
pipeline
be
much
more
dynamic
than
they
are
today
and
but
more
than
that,
there
are
like
really
specific
use.
Cases
that
our
user
would
like
to
have.
A
One
of
them
is
to
create
to
allow
organization
to
create
a
single
pipeline
entry
and
then
allow
user
to
always
include
their
specific
configuration
or
specific
actions
in
that
pipeline.
So
it
will
enable
standardization
but
allow
user
to
also
customize
and
customize
their
pipeline.
Also,
there
is
a
use
case
where
users
would
like
to
create
a
shared
library
of
primitive,
and
that
will
help
developers,
including
those
in
the
in
the
pipeline,
configuration
based
on
different
conditions.
This
is
exactly
what
this
issue
can
can
do.
A
You
can
read
more
about
those
use
cases
here
in
some
of
the
comments
that
we
have
from
our
users
by
the
way
it
will
also
help
the
compliance
team
and
with
some
of
the
work
that
they
are
doing
about
with
compliance
pipeline
and
so
really
looking
forward
for
this
issue
to
be
implemented
and
get
feedback
from
our
users.
A
A
Editor
today,
pipeline
editor
support
only
working
from
your
master
or
your
main
branch
and
again
this
is
this
is
an
issue
that
we've
worked
for
several
iterations,
but
we
found
several
blockers
and
you
can
see
it's
issue
number
three
number
four
that
prevents
us
from
releasing
this
this
feature,
so
hopefully,
once
we'll
get
those
results
we'll
be
able
to
release
this
one
for
four
users.
A
A
It
should
go
more
deeply
in
the
work
that
we
are
doing
on
the
template,
but
this
is
a
mvc
right
now
we
don't
have
a
anything
that
is
related
to
template
in
the
pipeline
editor,
and
we
know
that
the
python
ito
is
your
one-stop
shop
for
creating
updating
your
pipeline,
and
we
know
that
template
is
something
that
will
help
users
get
started
with
with
pipelines
and
nci
and-
and
we
are
lacking
that
so
the
mvc
is
quite
simple-
is
just
to
add
a
single
button
that
will
redirect
our
users
to
our
templating
library.
A
So
this
this
button
will
open
a
pop-up
to
the
templating
library,
where
user
can
scroll
and
search
for
different,
different
templates
that
we
have
and
then,
when
they
look
at
the
template,
they
can
simply
copy
paste
it
into
into
the
pipeline
editor.
We
are
also
tracking
the
telemetry
of
number
of
clicks
that
users
are
clicking
on
on
this
button.
This
is
where
we
can.
A
We
can
determine
if
this
is
something
that
the
user
would
like
to
do
and,
as
I
mentioned
hypothesis,
is
that
users
would
like
to
start
working
with
templates
before
they
even
start
getting
their
pipeline
and
more
more
into
that
into
this
issue
and
the
success
metric
for
the
telemetry
we
are
collecting
this.
Is
it
I'm
gonna
pass
it
over
to
nadia.
She
can
talk
about
the
scope
of
work
for
you
ex.
Thank
you.
B
Hey
everyone,
so
I
just
wanted
to
highlight
some
of
the
top
priority
items
for
ux
13.1
in
14.1.
I
will
be
continuing
my
work
around
the
vision
for
cic
templates
usage
and
creation
for
large
enterprise
organizations,
so
we
want
to
explore
solving
such
problems
as
enforcing
templates
across
projects
in
organization
having
centralized
pipeline
creation
tools,
so
allowing
you
to
create
a
library
of
your
own
custom,
ci
templates
and
creating
an
easy
way
to
distribute
them
across
all
of
the
projects
in
your
organization.
Things
like
that.
B
So
it's
a
pretty
big
effort
that
was
started
in
14.0,
where
I've
conducted
some
competitor
evaluation
gathered
some
interesting
insights
around
how
some
of
our
competitors
are
solving
this
these
problems
and
currently
dove-
and
I
are
also
running
a
problem-
validation
issue-
to
learn
more
from
our
customers
about
how
they're
currently
solving
these
problems
and
what
are
the
opportunities
for
us
there
to
provide
a
better
solution.
B
So
here
are
some
of
the
questions
that
we'll
be
asking
like:
how
do
you
ensure
standardization
of
cict
workflows,
currently
who's
responsible
for
creating
those
templates?
How
do
you
ensure
compliance
and
all
kinds
of
things
like
that?
So
once
we
get
answers
to
these
questions
and
gather
more
insights,
I'll
be
working
on
visionary
mockups
for
this
feature
set.
So
I'm
really
looking
forward
to
that
and
can't
wait
to
share
the
vision
with
everyone
and
start
iterating
on
it
with
the
team.
B
Another
big
effort
will
be
continuing
solution.
Excuse
me
continuing
solution,
validation
for
the
pipeline
graph.
So
after
we
implemented
the
job
dependencies
view,
we've
gathered
lots
of
feedback
around
the
job
dependencies
view
and
some
of
that
feedback
was
quite
straightforward,
but
some
other
problems
were
not
as
black
and
white
and
we
need
some
additional
insights
around
that.
We
need
to
better
understand
how
we're
going
to
prioritize
all
of
those
follow-up
issues
that
we
created
and
what
those
solutions
exactly
should
be.
B
So
I
want
to
use
this
opportunity
to
follow
up
with
some
of
the
people
who
commented
on
our
async
feedback
issue.
We
got
lots
of
feedback
from
our
current
customers,
so
I
want
to
actually
get
on
a
call
with
them
and
ask
additional
questions,
and
I
also
want
to
generally
gather
more
insights
around
popular
pipeline
visualization
like
what
are
the
different
types
of
information
you're.
Looking
for
when,
why?
B
How
do
you
troubleshoot
your
pipeline
architecture
to
optimize
it,
and
what
are
what
is
the
information
that
you're
looking
for
at
different
points
in
time
as
you
go
through
this
process?
So
these
will
be
the
major
efforts
that
I
will
be
working
on.
That
will
help
us
really
improve
the
user
experience
for
architecturing
your
pipeline,
making
it
more
efficient
and
also
for
creating
a
more
standardized
or
standardizing
the
workflows
across
your
organization.
So
all
of
that
will
hopefully
help
us
create
more
reliable,
more
efficient
pipelines.