►
A
Hey
everyone:
my
name
is
jason
javorska
and
I'm
the
product
director
for
ci
cd
here
at
gitlab
and
I'm
doing
the
kickoff
for
the
ci
team.
What
you'll
find
is
that
there's
actually
going
to
be
another
recording
as
well.
This
one
is
going
to
be
focused
on
authoring
and
pipeline
design
features
and
our
other
pm
tao
yeager,
along
with
vitico
who
joins
me
on
this
call
we'll
be
talking
about
pipeline
interactions
and
processing
and
that
sort
of
thing
features
related
to
that
yeah
vita.
Would
you
like
to
introduce
yourself
as
well.
B
Yeah
sure
I'm
vitika,
I'm
the
product
designer
for
ci
crew,
wi-fi
stage.
A
Great,
so
here's
our
list
of
what
we're
planning
on
doing
in
the
13.4
release,
so
I'll,
just
I'll
just
walk
us
through
one
by
one,
we'll
open
up
a
couple
as
well
and
and
dive
into
the
details.
The
first
item-
and
these
are
sorted
by
popularity,
so
the
more
the
more
interesting
ones
potentially
for
you
will
be
up
front-
is
allowing
optional
caching
in
failed
builds.
A
A
And
then
the
build
will
fail
because
of
some
other
mistake
or
whatever,
as
you're
iterating
on
the
pipeline
and
then
right
now
it
just
throws
away
the
cash
so
the
next
time
you
run
another
pipeline,
it's
going
to
rebuild
the
npm
cache
and
really
in
a
lot
of
cases,
you
want
to
be
able
to
say
I'm
doing
something
like
caching,
external
dependencies,
npm
or
gems,
or
for
ruby
or
whatever,
like
rust,
for
cargo,
and
I
just
want
to
have
my
cash
in
if
my
pipeline
fails.
A
It's
actually
nothing
to
do
with
my
cache,
so
just
always
update
it,
and
so
what
this
new
keyword
will,
let
you
do
is
say
I
want
my
cash
to
be
persistent,
even
if
my
pipeline
fails.
A
A
Where
you're
not
doing
that
or
if
you're
early
days
and
you're
just
kind
of
getting
everything
working,
and
you
want
to
have
it
temporarily
on
until
you
turn
it
off
later,
this
will
speed
up
that
initial
iteration
cycle.
For
you,
the
next
one
is
allowing
child
pipelines
to
trigger
their
own
child
pipelines.
A
I
think
we're
probably
just
going
to
add
one
level
to
this,
where
you
can
have
the
parent
pipeline
the
child
pipeline,
and
then
the
child
pipeline
can
trigger
one
more
level,
it's
sort
of
generally
useful
for
any
use
case
related
to
child
pipelines,
but
really
where
this
shines
is
when
it
relates
to
dynamic
child
pipelines,
and
if
you
want
to
be
able
to
generate
in
your
parent
pipeline
initially,
you
may
want
to
just
run
a
script
that
generates
the
state
of
the
world
and
starts
a
a
job
that
then
goes
out.
A
Looks
at
your
entire
mono
repo
finds
all
the
folders
that
have
changes
in
them
maps
out
all
the
dependencies
and
does
something
really
clever.
Well,
what
you
actually
want
there
is
to
start
to
have
that
child
pipeline
be
able
to
dynamically
generate
one
more
pipeline
in
be
able,
in
order
to
be
able
to
dynamically,
generate
all
of
those
jobs.
So
this
will
let
you
do
that
and
we
hope
that
it.
A
It
makes
a
big
difference
for
those
use
cases,
and
especially
teams
that
are
trying
trying
out
child
pipelines
and
have
been
blocked
so
far
on
that
one.
This
one
is
a
bug
fix,
so
triggering
multiple
dynamic
child
pipelines
causes
all
the
ones
to.
B
A
That,
obviously
shouldn't
be
happening,
so
we're
going
to
be
correcting
that
in
this
one
it's
a
popular
issue,
another
fix
for
child
pipelines.
It's
a
big
focus
for
us
over
the
next
few
releases
to
work
out
a
lot
of
the
bugs
in
in
the
dag
child
parent
pipelines
and
with
the
rules.
Keywords
so
you'll
see
a
lot
of
those.
But
what
this
is
is
it's
related
to
processing
of
the
child
pipeline
and,
if
you
retry
it
in
the
parent,
it's
not
pri,
it's
not
propagating
to
the
child.
A
A
So
just
some
more
fixes
coming
in
related
to
bridge
pipelines,
the
ability
to
render
a
processed
or
merged
gitlab
ciaml
file
is
a
nice
one
related
to
authoring.
A
So
once
you
start
using
includes-
and
those
includes
have
includes-
it
can
become
quite
complicated
in
your
head
to
imagine
what
the
merged
gitlab
ci
aml
is
that
gitlab
is
going
to
be
processing.
It
can
become
quite
complex
to
think
about
it
all.
So
what
this
is
going
to
do
is
add
an
endpoint
ux
feature
to
be
able
to
say
you
know,
do
the
linting,
but
then
also
just
send
me
back.
A
A
In
those
more
complicated
scenarios-
okay,
here's
that
other
issue
that
I
was
talking
about
related
to
downstream
jobs,
not
updating
the
upstream,
adding
variable
expansion
needed
for
the
ref
keyword
within
needs.
So
if
you
want
to
tell
a
need
a
jaw,
a
needs
job.
A
This
is
related
to
the
dag
that
it
once
you
want
it
to
use
a
certain
ref
when
it
is
triggering,
then
you
have
to
hardcode
that
ref
in
there,
but
we're
adding
the
ability
in
this
release
to
be
able
to
specify
that
with
a
variable
as
well
so
that'll.
B
A
You
a
little
bit
more
flexibility
in
pipeline
authoring.
Next
up
is
raising
the
user
limit
on
died
relationships,
so
the
limit
right
now
is
15,
I
believe,
possibly
10,
but
I'm
pretty
sure
it's
15.
and
we're
going
to
be
raising
that
to
50.
A
and
that's
the
relationship
between
one
job
to
its
children,
so
that
should
help
unlock
more
advanced
use
cases
with
the
dag.
A
The
reason
we
had
had
a
limit
on
it
before
was
due
to
performance
monitoring,
but
we've
made
some
performance
improvements
related
to
dag
calculation
and
monitored
those,
and
things
should
be
going
well,
so
we're
planning
on
just
opening
that
up
and
then
continuing
to
iterate
on
that
over
time
to
increase
the
dag
limit,
probably
over
a
little
bit
each
over
the
next
few
releases
and
then
improving
the
navigation
between
parent-child
pipelines
is
one
of
the
first
ones
that
we're
looking
at.
That
has
some
ux
here.
A
But
this
is
all
about
making
it
more
seamless
and
I'd
say:
that's
our
goal
is,
is
making
it
more
seamless
when
you're,
navigating
between
a
parent
to
a
child,
to
its
children
and
and
just
smoothing
that
all
out,
but
with
the
details.
I
want
to
turn
this
over
to
vita,
to
talk
about
her
thinking
here
in
this
design.
B
Sure
and
susan,
so
if
we
look
at
the
design,
doesn't
could
you
click
on
the
tab.
B
B
Yeah,
so
if
you
look
at
this
like
the
bridge
jobs
when
they
are
triggering
a
downstream
pipeline
earlier,
what
was
happening
is
the
moment
we
click
on
the
downstream
pipeline.
There
was
no
relation
like
no
visual
relation.
You
could
make
to
the
trigger
job.
So
now,
as
long
as
you're
looking
at
any
downstream
pipeline,
the
trigger
job
would
remain
highlighted.
That's
the
first
thing
and
the
next
one
is
earlier.
B
This
entire
tile,
the
downstream
pipeline,
was
clickable
and
when
you
click
on
it,
it
used
to
open
the
child
pipeline
or
downstream
pipeline
on
the
side.
But
now
we
have
made
like
small
parts
of
it
clickable
so
that
we
can
include
more
triggers
inside
the
tile.
For
example,
if
you
click
on
the
id
of
the
child
pipeline,
you
will
go
to
the
page
that
would
give
you
details
about
the
child
pipeline
and
similarly,
if
you
click
on
the
cadet,
that's
on
the
right
hand,
side.
B
It
would
just
expand
the
pipeline
and
you
can
also
close
it
from
there.
That's
all.
A
Cool
yeah,
that's
gonna,
be
so
so
much
nicer,
so
yeah
improving
navigation
there.
This
one,
this
one
is
not
100
locked
here,
but
I
can.
I
can
talk
about
what
we're
still
thinking
about
so
right
now
we
have,
if
you're,
using
the
needs,
keyword
and
using
a
dag
pipeline.
A
The
way
when
manual
behaves
is
different.
It
sort
of
makes
sense
on
the
one
hand,
in
that,
if
you
say
I
need
another
job,
that's
manual,
then
you
kind
of
want,
maybe
that
pipeline
or
that
job,
to
wait
on
the
manual
job
and
just
kind
of
sit
there
idling,
but
that's
actually
not
what
happens
in
stage
processing
where,
if
you
are
in,
if
you
have
a
job
in
a
stage,
that's
after
a
manual
job,
it
will
just
immediately
run
it
so
that
inconsistency
is
causing
a
lot
of
confusion.
A
There's
also
kind
of
like
how
allow
failure
behaves
in
the
mix
there
as
well,
and
what's
not
locked
in
about
this
yet
is
we
don't
want
to
make
this
change
in
a
way
that
you
cannot
configure
things
to
work,
the
way
that
it
does
today?
It
will
be
a
breaking
change,
unfortunately,
and
we'll
be
deprecating,
we'll
be
sending
a
deprecation
notice
in
a
previous
release
13.3,
but
the
yeah
the.
What's
the
best
way.
A
To
put
this,
the
other
issue
that
we're
looking
at
that
we
might
put
in
13.4
instead
of
this
one
and
then
move
this
one
to
13.5
is
related
to
one
of
those
use
cases
where
you
know
people
want
to
be
able
to
say.
I
want
this
to
block
explicitly
or
I
don't
want
this
to
block
explicitly,
and
we
have
to
think
about
how
that
relates
to
allow
failure
and
when
manual,
so
we
want
to
make
sure
we
do
the
right
thing
before
we
do
any
kind
of
breaking
change.
A
So
that's
the
last
bit
of
discussion.
That's
still
happening.
If
that's
the
case,
then
that
issue
will
move
into
13.4,
which
is
not
a
breaking
change.
It
just
adds
a
new
keyword
and
then
we
will
move
this
breaking
change
into
13.5,
but
something
to
be
aware
of
and
yeah
something.
That's
coming
there'll
be
more
details
coming
on
that
in
the
deprecation
notice
that
comes
with
13.3,
showing
the
relevant
values
for
job
names
and
matrix
builds
matrix.
A
Build
was
an
awesome
feature
that
we
released
just
recently
13.2,
I
believe,
or
maybe
the
very
beginning
of
13.3
and
what
it
does
is
it
lets
you
define
a
matrix
like
like
here
where
you
can
see.
You
know
on
the
one
axis
of
the
matrix,
you've
got
the
stack
and
the
other
you've
got
provider,
and
then
we
automatically
create
all
of
the
jobs
for
you
well
what's
happening
today.
A
Is
that
it's
just
showing
a
job
name
like
one
of
two
or
you
know
in
this
case
it
would
have
been
one
of
eight
or
whatever.
If
I
do
the
math
real
quickly
and
instead
we
want
to
show
what
the
you
know.
The
values
for
the
two
variables
are
in
every
case,
because
you
know
if
you've
got
this
matrix
here
and
you
just
see
this
list,
you
sort
of
have
to
open
up
them
all
in
order
to
see
which
one
is
the
one
you're
looking
for.
A
But
if
the
jobs
are
named
something
like
this,
then
it
would
just
be
very
clear
at
a
glance
what
what
you're
looking
at
so
that's
that
fix
and
then
the
last
one
we
have
is
making
the
web
ide
the
preferred
experience
for
editing
the
gitlab
ci
aml,
and
what
this
is
about
at
an
overall
level.
Is
that
we're
adding
a
lot
of
great
features
to
the
web?
A
Ide
syntax,
highlighting
there'll
be
visualizations
and
other
cool
things
coming
and
right
now
the
default
experience
is,
if
you
click
on
the
you
know,
add
gitlab
cim
onto
this
product
or
edit
gitlab
ciaml.
Then
you
just
go
to
the
single
file
editor
and
we
want
to
change
that
to
be
by
default.
The
nicer
experience
so
with
that
I'll
turn
this
one
over
to
you
also
avitaco.
B
Sure,
thanks
susan.
So
if
you
look
at
the
screen
in
the
design
proposal,
we
are
proposing
to
add
this
banner
and
alert
banner
at
the
top.
That
would
tell
users
about
what's
available
in
the
web
ide
and
how
they
would
be
getting
a
better
experience
in
editing
their
gitlab
ci
yaml
file.
If
they
move
to
the
web
ide-
and
we
are
also
providing
a
trigger
from
the
banner
itself
from
where
they
could
take
their
content
straight
away
to
the
and
open
it
straight
away
in
the
web.
Ide.
A
Right
yeah,
so
this
would
be
what
you'd
see
in
the
single
file
editor
just
kind
of
like
a
note
that
you
can
go
there,
but
this
was
the
button
that
I
was
talking
about
where
you
can
set
up
cid
cd.
We
won't
take
you
to
the
single
file
editor,
which
then
has
a
note
that
there's
a
better
editor.
This
will
just
take
you
directly
to
the
to
the
web.
Ide,
so
that'll
be
nice.
I
think,
and
the
the
editing
experience
really
is
growing
quite
a
lot.
A
A
So
that's
it
for
us
anything
else
that
you
wanted
to
add.
Pizzagun
overall.
A
Cool
well
hopefully,
these
are
some
exciting
features
related
to
authoring.
Hopefully,
this
new
format,
where
we're
talking
about
authoring
and
pipeline
design
in
a
separate
video
is,
is
interesting
as
well,
but
yeah
thanks
for
watching
and
until
next
time.