►
From YouTube: GitLab 13.5 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
Hello,
my
name
is
jason
jovoskian,
I'm
the
product
director
for
ci
cd
here
at
kit
lab-
and
this
is
the
community
hi
everyone.
My
name
is
davos
govitz
and
I'm
a
senior
product
manager
for
the
pipeline,
also
in
gold,
and
so
this
is
the
kickoff
for
the
pipeline
authoring
team,
which
is
a
new
team
at
gitlab
at
the
moment,
is
the
non-marketing
category
that
we've
got
that
helps
us
split
out
what
we're
doing
across
sea
ice.
A
It's
such
a
large
category-
and
this
group
in
particular,
is
focused
on
writing
pipelines
defining
how
they
work
and
what's
supposed
to
happen,
and
then
the
continuous
integration
team
that
you
might
be
already
familiar
with
is
responsible
for
actually
executing
those
things
and
interacting
with
them
when
once
an
actual
pipeline
is
running
so,
like
you
might
imagine
like
filtering
pipelines
and
that
sort
of
thing.
A
So
all
the
issues
that
we'll
talk
about
today
are
about
writing
pipelines,
setting
them
up,
and
that
sort
of
thing
we'll
start
over
here
on
the
right
side
of
the
column
with
work,
though
the
in
in
already
in
development
items
which
are
just
started,
and
then
the
ready
for
development
items
as
well
and
I'll
just
go
through
each
of
these
in
a
tab
here.
A
So
the
first
item
is
an
improvement
to
our
matrix
pipelines
that
we
released
recently
where
you
can
set
up
a
a
parallel
job,
just
like
it's
done
here,
but
there's
a
limitation
there
in
the
initial
version
that
we
came
out
where
you
have
to
have
two-dimensional
array
in
order
to
make
the
matrix,
which
is
technically
true,
you
have
to
have
in
order
for
it
to
be
a
matrix.
A
You
need
two
dimensions,
but
there's
also
nice
use
cases
where
you
just
want
a
job
to
iterate
over
a
single,
one-dimensional
array,
for
example,
in
this
case
in
the
example,
it's
iterating
over
just
a
single
list
of
providers.
So
what
this
will
do
is
create
a
job
called
deploy,
stacks
gcp
and
a
job
called
the
place
next
filter
and
then
run
this
command
for
each
one.
This
is
a
nice
improvement.
A
A
few
people
have
asked
for
this
and
it's
something
that
we're
pretty
excited
to
get
out
there,
just
as
a
easy,
quick
win
improvement,
something
that
I'm
actually
personally
working
on
is
creating
a
new
dynamic
child
parent
pipeline
template
that
uses
d-hall.
A
We
recently
released
one
for
jsonnet,
which
maybe
you
see
that
will
allow
you
to
use
dynamic
child
pipelines,
which
is
basically
just
generating
your
gitlab
ci
aml
at
runtime
and
then
executing
it
using
json,
which
is
a
nice
templating.
Language
d-hall
is
another
really
popular
one
and
so
I'll
be
looking
at
implementing
some
kind
of
basic
child
parent
pipeline
using
d-hall
that
you
can
use
as
a
customization
point
to
start
doing
your
own
pipeline,
allowing
our
needs
dynamic.
A
I'm
sorry,
directly,
sickly
graph
pipelines,
three
first
job
in
the
same
stage,
so
one
of
the
not
arbitrary,
I
guess,
but
one
of
the
iterations
that
we're
working
forward
on
on
the
factory
civic
craft
is
that
you
right
now
you
have
to
have
the
jobs
refer
to
only
other
jobs
that
are
in
different
stages.
So
if
you
have
a
deploy
job
that
depends
on
a
bunch
of
build
jobs,
that
totally
makes
sense
and
you
can
have
them
relate
to
each
other.
A
But
if
you're
really
going
all
in
with
the
diag
pipelines,
you
may
want
to
just
have
one
big
stage
and
then
just
within
that
stage
have
everything
referred
to
each
other
and
just
be
one
big
graph.
All
in
a
stage
called
like
do
everything
or
whatever
or
you
may
just
have
within
your
build
stage,
some
things
that
depend
on
each
other
in
some
order
and
you
still
they're
still
all
related
to
the
build.
A
A
Rules
changes.
So
we
had
this
rules
feature
recently
and
it
just
like
only
accepts
supports
changes
to
files.
So
you
can
say
I
only
want
to
run
this
job
if
there
are
changes
to
files
in
this
folder
or
whatever,
and
you
might
use
that
if
yeah,
if
you're
doing
a
monoreaper
or
something
like
that,
you
could
have
say
only
run
the
pipeline
or
the
job.
For
this.
You
know
component
in
my
mono
repo.
A
If
there
are
changes
in
the
files
for
that
component,
that
changes
parameter
doesn't
support
variables,
though.
So,
if
we
look
down
here,
you
can
see
this
would
not
be
possible
today,
where
we're
using
a
helmeter
variable
along
with
a
path
back
here.
So
this
is
going
to
be
adding
that
so
that
you
can
use
a
variable
and
then
not
have
to
hard
code
all
of
your
paths
in
all
the
cases
which
would
be
nice.
A
A
So
this
is
just
fixing
that
it'll
make
it
easier
and
it'll
make
this
use
case
possible.
A
Another
really
really
nice,
one
that
I'm
excited
about
here
is
supporting
multiple
artifact
sets
per
a
single
job,
that's
actually
already
possible.
On
the
back
end,
if
you're
using
features
like
code
quality,
you
know
that
one
job
can
actually
generate
multiple
kinds
of
artifacts,
but
we
don't
expose
that
ability
on
your
own.
We
only
kind
of
do
it
on
the
back
end
for
some
of
the
good
quality
things.
So
what
we'll
do
here
is
add
a
new
ciemo
syntax
to
support
multiple
artifacts,
that's
independent.
A
That
can
then
be
uploaded
separately,
downloaded
separately
all
coming
from
a
single
job,
and
you
might
do
that.
For
example,
if
you
have
one
job
that
builds
like
a
debug
target
and
a
release
target
in
a
single
case,
it
can
then
upload
those
both
separately
instead
of
having
you
know,
everybody
have
to
download
both
at
once
and
there's
other
similar
use.
Cases
trigger
pipeline
is
another
feature.
We've
come
out
recently
that
we're
making
nice
improvements
to
and
right
now
a
triggered
pipeline
can
only
run
immediately.
A
A
Supporting
one
manual
on
trigger
pipelines
will
add
that
ability
to
have
those
triggered
pipelines
then
only
run
when
you
press
play
automatically
loading
and
validating
the
default
config
within
the
eyelet
tool
yeah.
This
is
a
this
is
a
really
really
nice
one
that
has
come
up
over
a
long
time
we're
finally
getting
around
to
so
when
you
open
the
linter
for
a
project,
and
I
guess
it
was
about
six
months
ago
we
moved
the
winter
to
be
inside
of
the
project
itself.
A
You
just
get
a
blank
screen,
which
is
nice
if
you're
just
starting
with
something
fresh,
and
you
want
to
start
editing
but
a
lot
of
times.
You
are
wanting
to
do
a
customization
of
your
gitlab
ciam
and
see
if
it's
going
to
work
or
not.
A
So
what
we're
going
to
do
now
is
automatically
load
in
the
gitlab
ci
animal
for
the
project
and
automatically
actually
do
a
single
validation
pass
as
well,
and
so,
when
you
load
up
the
linter,
your
gitlab
ciemo
will
be
there.
A
During
pipeline
creation
is
also
something
that's
been,
a
focus
for
us
and
what
this
feature
is
going
to
do
is
link
to
the
documentation
for
any
errors
that
we're
showing
we're,
starting
out
with
just
a
small
subset
of
the
errors
that
we're
going
to
prove
this
feature
out
in
this
iteration,
but
then
there's
three
follow-up
issues
which
are
part
of
the
epic
that's
linked
to
here,
which
we'll
be
going
after
different
classes
of
errors
that
we
have,
and
over
the
next
couple
of
releases,
we'll
be
working
through
the
mom
and
adding
links
to
the
documentation.
A
So
we
hope
that
you
know
when
a
pipeline
starts,
and
you
see
some
error
message.
You
know
something
like
this
build
job
need
test
is
not
defined
in
prior
stages.
You
know,
maybe
you
know
what
that
means.
A
Maybe
maybe
you
don't
but
we're
going
to
link
now
to
the
documentation
to
help
you
understand
what
that
means,
if
you're
not
sure
and
that'll,
be
a
nice
improvement
for
anybody,
who's
doing
troubleshooting
and
then
finally,
we
added
lint
warnings
recently
as
well
that
give
you
a
heads
up
that
something
looks
odd.
It
will
run,
but
it's
not
maybe
going
to
do
what
you
expect
and
those
were
added
to
the
ui,
but
they
were
not
added
to
the
api.
A
So
that's
it
for
pipeline
authoring.
Overall,
our
focus
has
been
on
just
kind
of
making
that
you
know
time
to
your
first
green,
build
easier
when
you
set
up
a
new
project
and
you're
just
you
know
getting
your
gitlab
ciamo
written
running
it
for
the
first
time,
maybe
having
a
couple
errors
and
then
troubleshooting
and
understanding
that
I
hope
that
you
can
see
that
all
of
these
things
add
up
to
making
that
process
easier
and
more
fun.
Hopefully
even
and
yeah
we'd
love
to
hear
your
feedback.