►
From YouTube: GitLab 15.2 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,
everyone,
my
name
is
dr
kovitz,
and
this
is
the
pipeline
authoring,
15.2,
kickoff,
video
and
before
we
begin
just
a
reminder
that
during
this
milestone,
we
are
going
to
have
a
week
long
of
a
hackathon,
and
this
is
why
I
try
to
make
the
list
of
items
keep
it
to
the
minimum
for
this
iteration.
A
So,
let's
dive
in
a
couple
of
issues,
I
would
like
to
call
out
and
issue
number
one
is
simulating
pipelinization
under
condition,
and
so
right
now,
when
the
users,
our
users,
are
writing
their
pipeline
in
the
pipeline
editor
they
can
validate
if
the
syntax
is
correct
and
if
the
logic
of
the
pipeline
that
they
are
writing
is
correct,
but
there
is
no
way
for
them
to
validate
how
the
pipeline
will
look
like
based
on
the
different
rules,
the
different
conditions,
and
that
they
write,
because
each
pipeline
can
behave
differently
from
each
other,
and
this
is
the
capability
that
we
have
today
in
the
ci
lean
tool,
but
it
is
very
hidden.
A
So
what
we
outline
is.
We
would
like
to
move
this
to
the
front
center
and
we
are
going
to
replace
the
lint
tab
that
we
have
today
in
the
pipeline
editor
with
the
simulation
of
the
pipeline
creation.
I'll
show
you
how
it
will
look.
So,
let's
assume
that
you
have
a
pipeline
that
you're
writing
in
in
your
pipeline
editor.
So
you
have
the
new
tab
and
which
will
be
called
validate
and
will
be
highlighted
by
this
new
banner
and
when
user
will
go
into
the
tab.
They'll
have
a
call
to
action
button.
A
This
one
they
can
validate
in
their
pipeline
and
we
are
writing
and
that
we
are
going
to
simulate
the
whatever
they
include
in
the
edit
tab
and
we
are
going
to
include
all
the
orders.
The
different
condition
would
only
accept
and
the
needs
dependency
and
provide
them
with
an
output
of
how
their
pipeline
in
confirmation,
if
the
pipeline
will
work
based
on
this
order.
As
I
mentioned
right
now,
we
are
only
in
the
pipeline
editor.
A
We
are
only
validating
the
whole
part
of
the
entire
pipeline
without
taking
into
consideration
those
those
different
conditions,
yeah
and
obviously
we'll
be
able
to
iterate
and
add
more
conditions
as
we
go
with
different
inputs,
different
variables
and
more
so
this
is
just
the
mvc
for
for
the
spider
simulation,
and
the
second
issue
is
actually
about
the
jwt
token
open
id
connect
support.
So
it's
a
part.
A
It's
the
backend
work,
but
it's
a
part
of
a
bigger
epic
and
the
openid
connect
is
a
standard
that
is
being
used
across
many
cloud
providers
and
other
third
party
and
will
allow
gitlab
to
authenticate
against
those
providers
and
retrieve
secrets
and
and
the
back-end
work
for
that.
We're
actually
doing
a
couple
of
things
in
the
background
and
number
one
and
we
are
making
the
openid
connect
support
for
the
jwt
token
and
number
two.
A
We
will
allow
users
to
opt
in
the
token
for
each
job,
and
this
is
mainly
in
order
to
secure
the
workflow
of
a
of
our
cast
of
our
users,
because
right
now
the
token
is
available
across
all
all
pipelines
and
all
jobs-
and
this
is
not
a
secure
method,
because
polytech
is
only
takes-
is
one
compromised
job
in
order
for
the
stocking
to
leak.
A
So
the
idea
is
to
allow
users
to
opt-in
for
a
specific
job
and
say:
okay,
I
want
the
token
to
be
scoped
only
for
those
jobs,
because
there
is
no
need
to
expose
this
token
to
all
jobs
across
all
your
pipeline.
And,
lastly,
we
would
like
to
allow
user
to
configure
the
audience
claim.
A
It
is
called
odd
aud
and
you
can
actually
see
the
full
information
in
this
issue
and
so
allowing
users
to
configure
the
audience
claim
is
also
another
method
securing
and
the
workflow,
because
the
audience
claim
is
the
claim
that
is
coming
up.
That
is
on
the
jwt
payload,
which
is
specifying
against
which
third
party
I
would
like
to
authenticate
without
the
audience
claim.
If
someone
is
retrieving
your
tech
token,
they
can
practically
authenticate
against
any
cloud
provider
they
want.
So
the
audience
claim
is
really
critical
in
order
to
secure
your
supply
chain.
A
A
But
when
we
look
at
all
of
those
issues,
we
kind
of
realize
that
before
we
start
implementing
those
issues
we'll
be,
we
need
to
do
some
back
end
work,
which
is
mainly
replacing
some
of
the
rest
api
with
with
the
graphql
and
once
we
do
it
we'll
be
able
to
then
pick
any
issue
that
we
want
and
implement.
It
incrementally
and
add,
like
this
value
to
our
user,
incrementally
at
the
value.
A
So
some
of
the
issues
that
we
would
like
to
tackle
in
the
future
once
we'll
complete
the
backing
book
is
using
the
special
character
in
variable
such
as
the
dollar
sign.
This
is
by
the
way,
the
most
popular
bug
in
gitlab
that
would
like
to
solve
and
two
other
very
popular
issues.
I
think
both
of
them
have
more
than
100
volts
is
to
retry
pipeline
with
custom
variables
right
now,
you
can
only
run
pipeline
with
custom
variable.
A
You
cannot
retry
pipeline
with
with
that
and
setting
a
predefined
list
when
you're
running
a
pattern,
predefined
list
of
variables
when
you're
running
a
pipeline
and
obviously
those
issues
will
will
be
follow-ups
after
we'll
complete
the
second
work
and
that's
it
with
that
said,
I'm
going
to
hand
it
over
to
nadia
and
she's
going
to
talk
about
this
cup
of
hope
for
your
ex.
Thank
you
and
bye,
bye.
B
C
Everyone
in
15.2,
I
will
be
continuing
my
work
on
the
pipeline
components.
Mvc.
Our
goal
is
to
finish
up
the
solution,
validation
for
pipeline
components
and
the
interview
is
already
done
so
I'll,
be
working
on
summarizing
the
insights
and
then
using
them
to
inform
further
design
refinement,
which
leads
me
to
the
design
issue
that
I
will
continue
to
work
on,
and
it
will
go
through
another
round
of
design
iteration.
C
Based
on
the
insights
that
we
get
from
solution.
Validation
we've
been
getting
some
really
interesting
insights,
so
I'm
very
excited
to
see
how
we
can
refine
this
proposal
and
get
it
ready
for
implementation,
hopefully
in
15.4,
but
we'll
see
how
it
goes.
Other
than
that
I
will
be
working
on
some
other
usability
improvements.
One
of
the
issues
is
around
improving
the
behavior
of
the
scroll
bar
in
the
pipeline
graph.
C
Currently,
the
scroll
bar
is
hidden
at
the
very
bottom
of
the
pipeline
graph,
which
makes
it
difficult
to
horizontally
scroll
on
the
graph
for
some
of
our
users,
so
I'll
be
investigating
this
issue
and
there's
some
other
carryover
discussions
that
are
happening.
One
interesting
issue
that
I'm
working
on
is
to
run
merge
results
pipelines
automatically
when
a
merge
request
leaves
the
draft
state.
So
generally,
when
emerge
request
is
an
address
state.
C
You
want
to
run
shorter
pipelines
to
make
it
easier
for
you
to
iterate
on
the
mr
and
then
once
the
the
mar
is
marked
as
ready.
You
want
the
merge
results
pipeline
to
run,
so
you
can
make
sure
that
whatever
changes,
you're
making
they're
actually
good
and
aren't
gonna
break
the
production
so
yeah,
it
seems
like
a
lot
of
users
are
interested
in
this
issue,
and
I
just
want
to
make
sure
that
we
consider
other
possible
options
like
adding
a
setting
for
this.
For
example
yeah.
C
If
you
have
any
questions
around
this
work
or
if
you
want
to
provide
feedback
on
any
of
this,
for
example,
the
pipeline
components
feature
feel
free
to
jump
into
the
issue
and
bring
me
there.
Thank
you.