►
From YouTube: GitLab 13.7 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
If
you
didn't
have
the
time
and
if
we
scroll
further
down,
you
can
see
that
we
have
epics
and
sub
epics
and
issues
and
more
issues
and
most
of
the
issues
that
I'm
going
to
discuss
today
are
a
part
of
those
epics
and
in
south
epic.
So
everything
actually
or
most
of
the
things
will
contribute
to
our
tail
vision.
A
A
So,
a
couple
of
months
ago,
we've
decided
that,
in
order
to
improve
our
pipeline
authoring
experience,
we
would
need
our
users
actually
would
need
a
dedicated
authoring
area,
because
today,
when
you
create
or
configure
your
pipeline,
the
experience
is
the
same
as
you
update
or
configure
any
different
file.
So
there
is
nothing
special
about
that.
Although
defining
pipeline
is
important
and
we
want
to
make
sure
we
provide
all
the
features.
So
the
experience
is
very
fragmented.
A
So
this
epic
is
built
out
of
four
major
implementation
issues,
some
design
issue
and
some
some
solution,
validation
and,
and
also
a
couple
of
research
researches
that
that
we've
done
and
let's
go
over
those
implementation
issue.
The
first
one
is
a
static
representation
of
the
gitlab
ciam.
A
So
in
the
last
couple
of
iterations,
the
team
had
worked
on
visualizing
your
pipeline.
So
today,
in
order
to
see
how
the
pipeline
looks
like
you
need
to
push
the
change,
so
you
need
to
create
this
yaml
file.
You
need
to
push
it.
The
pipeline
need
to
run,
and
only
then
you'll
be
able
to
see
how
the
pipeline
looks
like,
and
in
with
this
feature
you
will
simply
add
a
visualization
tab.
A
Next,
to
the
place
where
you
will
update
your
your
pipeline
configuration
you'll
be
able
to
see
how
the
pipeline
looks
like-
and
this
is
like
this
is
the
this
is
also.
This
issue
is
like
an
mvc
for
our
pipeline
visual
builder,
but
this
is
something
that
will
come
in
the
next
in
the
coming
iterations
and
the
second
issue
is
the
ability
to
edit
your
pipeline.
A
A
As
you
type
your
your
configuration
we'll
be
able
to
provide
some
smart
suggestion,
we
will
have
like
syntax,
highlighting
and
and
autocomplete
and
lastly,
the
linter.
The
linter
is
a
tool
that
helps
you
validate
the
syntax
of
of
your
pipeline,
and
the
lender
today
is,
I
would
say,
it's
well
hidden,
it's
somewhere
in
the
pipeline
page,
there
is
like
a.
A
There
is
a
button
that
you
need
to
push
and
it
will
launch
the
the
lintel.
So
why
I
mean,
if
we
have
this
great
tool,
why
won't
we
put
that
as
another
tab,
so
we'll
simply
take
the
linter,
as
is
without
any
modification,
and
just
add
it
as
as
another
tab,
and
this
will
be
the
outcome
of
the
mvc
and
the
decision
to
remove
the
feature
flag
is
once
we
will
conclude
with
issue
number
one
and
issue
number
two.
So
those
two
issues
enough
to
to
lift
the
feature
plug.
A
A
A
There
is
a
serious
security
consideration
that
we
need
that
we
went
back
and
forth
and
because
of
that,
we've
decided
the
outcome
of
this,
and
I
won't
walk
you
through
this,
because
you
can
do
it
by
yourself,
but
the
outcome
of
it
means
that
this
feature
will
be
available
for
self-managed
and
dot-com
users,
but
dot-com
users
that
are
not
using
shared
runners.
So
because
you
will
need
an
admin
access
to
the
runner,
there
is
a
significant
amount
of
work
that
the
anarchy
needs
to
do,
which
is
which
is
as
an
administrator
of
the
runner.
A
A
A
block
and
merge
it
in
your
pipeline
configuration-
and
I
will
explain
it
with
an
example
but
before
that
this
issue
actually
is
a
follow-up
from
a
very
popular
issue,
and
you
can
see
more
than
more
than
100,
upvotes
and
yeah.
Sorry
about
that
yeah
as
we
went
back
and
forth.
This
issue
was
very
old.
Some
of
the
requirements
that
came
out
of
this
issue
are
already
available
today,
but
I
think
this
this
is.
A
This
is
a
a
critical
feature
that
that
we
are
missing
and,
as
I
mentioned
example
will,
will
be
the
easiest
way
to
explain
it.
So,
let's
assume
I
have
three
and
three
ml
files,
one
of
them
set
up,
and
I
have
a
predefined
script
for
setup
and
a
teardown
with
the
job
and
a
predefined
script
for
teal
down.
And
then
I
have
my
gitlab
crm.
A
Job
script
and
the
outcome
of
this
of
this
pipeline
is
is
a
merge
script
which
will
have
this
the
setup
script
and
then
my
own
commands,
if
I
want
to
and
then
the
till
downscape,
as
you
can
see
here,
and
the
value
for
this,
is
that
often
time
when
we
see
we
see
that
users
like
to
maintain
their
own
a
central
location
for
their
job.
A
Usually,
there
is
a
single
team
that
is
very
skilled
and
experienced
and
build
those
those
jobs,
and
there
are
other
teams
that
are
using
pipeline,
but
they
would
like
to
do
some
sort
of
a
reference,
so
they
normally
contact
this
team
and
and
ask
okay.
What's
the
latest
script
that
we'll
use?
What's
the
latest
features
and
so
on
and
so
forth,
and
they
need
to
write
those
skips.
A
So
in
this
way,
we'll
be
able
to
this
team
will
be
able
to
share
their
knowledge
by
allowing
teams
to
to
reference
to
those
to
those
to
those
jobs
that
are
located
in
a
in
a
central
location
without
these
features,
but
normally
what
users
are
doing
is
they
need
to
create
those
files
and
just
clone
it
to
their
ripple
and
then
every
time
that
they
need
to
and
the
the
they
need
to
update
a
specific
skill.
They
need
to
do
it
for
each
and
every
repo.
A
Highlighted
down
a
downstream
pipeline
when
hovering
a
trigger
job
yeah,
this
is
nice
improvement,
as
you
can
see,
when
you
hover
over
a
downstream
job,
we
we
highlight
what
was
the
trigger
job,
but
we
don't
do
this
when,
when
you
hover
over
the
trigger
job,
so
the
idea
here
is
when
you
hover
over
this
trigger
job,
we
will
highlight
the
downstream.
A
A
Okay,
another
one,
also
a
parent
child,
easier
identification,
and
there
is,
by
the
way,
a
lot
of
requirements
on
having
an
easy
way
to
identify
which
job
trigger
which
job.
When
we
are
talking
about
bridge
pipelines
and
so
in
this.
In
this
issue,
we
will
add
on
a
downstream
job.
We
will
add
a
text
which
will
mention
which
upstream
job
triggered
that
job.
So
you
can
see
this
child
pipeline
82
was
created
by
microservice
under
scopy.
A
And
the
last
one:
well,
it's
not
really
the
last
one,
because
there
is
an
addition.
Section
additional
section
is
to
support
multiple
cash
in
the
same
job.
So
today
we
support
multiple
cash
in
a
single
pipeline.
But
this
request
again
very
popular
one.
73
upvote
is
to
support
multiple
cash
in
the
same
job,
and
there
is
the
the
rationale
why
users
are
doing.
A
A
Okay,
this
is
it
for
the
scope
of
work
for
for
engineers.
But
there
is
another
section
that
I
want
to
call
out
which
that
is
in
in
this
iteration.
We
will
be
collaborating
with
the
growth
team
and
there
are
three
issues
that
the
growth
team
will
do
and
they
will
do
it
in
an
a
b
testing.
So
we'll
know
what
is
like
the
right
way
for
us
to
go
and
the
two
first
one
are
really
straightforward.
A
We
are
going
to
add
a
zero
state
page
for
for
the
jobs
and
and
the
pipeline
so
we'll
be
able
to
link
those
into
the
pipeline
authoring
area
that
I
explained
in
this
mvc
and
the
third
one
which
is
really
interesting,
is
to
provide
our
user
with
some
sort
of
an
empty
template.
Because
today,
when
you
come
and
write
your
pipeline,
you
will
see
an
empty
blank
page,
which
is
not
nice,
not
nice
experience,
and
in
this
issue
we
will
provide
our
user
with
some
sort
of
a
simple
hello
world.
A
Workflow,
so
they'll
be
able
at
least
to
see
how
how
a
basic
pipeline
configuration
looks
like
they
can
run
it.
They
can
see
that
it's
good
and
hopefully
it
will
increase
that
option
so
we'll
have
like
50
percent
of
our
user.
We
see
the
template
version
and
50
percent
of
the
user
will
see
the
control
version,
which
is
just
a
link
to
the
documentation.