►
From YouTube: GitLab Group Kickoffs - 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
Hi
everyone-
this
is
dave
heskovitz
and
here
with
nadyasa
pinkova,
our
ux
design-
and
this
is
the
python
authoring,
15.0,
kickoff,
video
and
as
always-
and
we
do
have
a
planning
issue
underneath
our
pipeline
authoring
group
issue,
number
44
and
the
goals
of
this
milestone.
Since
this
is
a
major
version,
is
implementing
some
of
the
breaking
changes
and
that
we've
announced
previously
this
year
and
some
security
and
open
some
security
issues.
A
And
I'm
gonna
talk
about
those
and
besides
those
improvements-
and
we
will
have
some
carryovers
from
previous
iteration,
because
in
the
previous
situation
the
team
was
focusing
mainly
on
security
issue.
But
I'm
not
going
to
talk
on
those
issues.
A
A
So
we
already
gone
through
the
entire
process
of
the
syntax
application
process,
where
we
first
announced
to
our
user
that
a
keyword
for
our
system,
syntax
is
going
to
be
removed.
A
The
second
issue
is
actually
the
second
and
the
third
issue
all
involve
the
jwt
token.
There
are
major
changes
that
are
happening
to
users
that
are
using
the
jwt
token.
Now.
The
jwt
token
is
the
token
to
allow
user
to
integrate
with
third
party
and
cloud
providers
such
as
vault,
microsoft,
azure
in
aws,
and
the
first.
A
The
first
change
is
making
the
jwt
token
open
id
connect,
compatible
and
open
id
connect
is
a
is
a
standard
in
the
industry
which
allows
users
to
connect
with
more
cloud
providers
and
up
until
today,
if
you
look
at
our
documentation,
you
see
that
we
have.
We
have.
We
have
three
types
of
the
jwt
token.
We
have
the
ci
job
jwt
and
we
have
v1
and
v2.
Now
v2
is,
as
you
can
see,
it
goes
in
an
alpha
state
and
the
v2
is
the
open
id
connect.
A
So
this
is
the
improved
token
and
basically,
what
we
are
doing
today
whenever
users
are
using
their
secret
keyword,
they
actually
use
the
j,
the
ci
job
jwt
token,
and
what
we
plan
to
do
in
this
iteration
is
basically
replace
behind
the
scene
in
the
jwt
with
v2,
so
by
default,
the
token
that
we'll
use
will
be
will
be
this
one
and
it
will
be
open.
Id
connect
obviously
involves
some
breaking
changes
to
our
users
that
are
integrating
with
vault,
and
we
also
have
an
issue
that
we
plan
to
properly
document.
A
A
They
need
to
configure
the
the
issue
claim,
but
we'll
have
the
proper
documentation
available
for
for
the
second
one
is
also
involved,
the
jwt
token
and
and
this
this
is
even
a
bigger
change
that
that
what
I've
previously
mentioned
and
right
now,
that
token
is
also
available
to
your
pipeline
to
any
job,
and
this
is
not
a
desirable
experience.
A
So
the
idea
of
this
issue
is,
first
of
all,
the
token
should
not
be
exposed
by
default
and
users
that
are
using
this
token,
for
a
specific
job
will
need
to
opt
it
in
in
the
yaml
configuration
and
we
are
talking
about
the
syntax
and
in
addition
to
that,
we
want
to
allow
user
to
configure
the
audience
claim.
A
The
obvious
claim
is
the
recipient
who
is
receiving
which
external
service
is
receiving
and
the
the
token
up
until
now,
what
we
didn't
have
that
we
have
a
way
to
configure
the
audience
claim
and
user
would
need
to
disable
the
audience,
which
means
that
they
could
interact
with
any
cloud
provider.
But
it's
not
a
it's,
not
a
secure
workflow.
You
need
to
mention
you
need
to
specify
which
which
which
telepathy
you
want
to
integrate.
A
So
those
are
the
two
changes
that
are
happening
in
in
this
in
this
issue,
and
I
think
we
do
have
a
a
convention
that
we
want
to
use.
Basically,
whenever
someone
wants
you
to
use
a
token,
then
when,
when
they
configure
the
job
name,
they
need
to
specify
secret
and
then
jwt
and
then
configure
the
audience
claim.
Okay,
this
will
ensure
that
first
of
all,
the
token
will
be
available
to
the
job
and,
with
this
audience
claim
that
we
have
here.
A
Lastly,
another
security
issue
that
which
is
kind
of
a
bug
is
that
whenever,
whenever
we
have
a
variable
that
is
type
file
and
we
assign
it
to
another
variable,
then
the
variable
that
was
assigned
is
not
a
type
type
file,
and
this
is
a
problem,
because
if
someone
is
echoing
that
file,
then
instead
of
printing
the
file
path,
we
are
printing
the
file
content,
which
is
it's
not
secure,
because
in
a
lot
of
cases
our
files
actually
contain
password,
and
we
don't
want
users
to
be
able
to
echo
and
print
those
passwords
in
in
in
their
log,
and
there
are
more
cases.
A
A
This
is
a
type
file
and
we
are
assigning
it
to
a
variable,
and
when
we
are
echoing
that
file,
you
can
see
that
we
are
printing
hello,
and
this
is
the
content
of
the
file
instead
of
the
path
of
the
file,
and
so
this
is
what
we
are
fixing
basically
and,
as
I
mentioned
besides,
that
we
are
going
to
roll
over
all
the
issues
from
fourth
intent
that
we
didn't
have
a
chance
to
work
on.
A
B
Thank
you
all
right.
Let's
dive
in
so
in
15.00,
we
will
be
continuing
mainly
our
work
on
the
cicd
component
catalog.
This
will
be
the
biggest
effort
that
I
will
be
taking
on.
So
you
can
see
this
issue
is
to
define
a
proposal
for
the
private
cicd
component
catalog
mvc,
so
we
spent
already
the
past
two
milestones:
exploring
a
visionary
direction
for
the
cicd
catalog
we've
had
lots
of
discussions
with
our
team.
We've
gathered
feedback
from
within
git
lab
and
we're
starting
to
converge
on
a
vision
that
we
agree
on.
B
B
It
might
take
us
a
bit
longer
than
a
milestone,
we'll
see
how
it
goes
and
our
goal
is
to
create
a
proposal
that
could
become
our
mvc
iteration
with
the
goal
of
eventual
dog
fooding
that
solution
within
gitlab.
B
B
So
there's
already
a
proposal
here,
but
there's
been
some
more
discussions
in
the
issue,
so
I
just
want
to
make
sure
that
we
consider
any
outstanding
questions
refining
the
proposal,
so
we
can
move
it
forward
and
resolve
this
problem
for
our
users,
the
main
problem
here
being
that
when
you
use
variables
for
a
manual
job,
when
you
run
your
manual
job,
those
variables
are
not
surfaced
in
the
job
round.
So
there's
no
way
for
you
to
to
know
exactly
what
variables
are
being
used
there.
B
So
I
will
just
be
revisiting
the
discussions
in
this
issue
to
see
what
are
the
options
available
to
us,
we're
considering
different
solutions
from
making
it
automatic
to
adding
some
kind
of
setting
that
you
would
be
able
to
configure
for
your
project.
Let's
say
you
could
say:
I
want
the
pipelines
to
run
automatically
in
my
mars.
If
I
remove
the
prefix
or
not
so
maybe
you
would
be
able
to
control
it,
so
we
will
be
working
a
proposal
for
this
in
this
milestone
as
well.
B
For
this
particular
issue,
we'll
be
solving
a
problem
of
expanding
variables
with
the
dollar
sign.
So
well,
it's
not
necessarily
a
problem,
it's
a
feature,
but
it's
a
problem
in
some
cases
when
it's
not
the
desired
behavior,
so
sometimes
you're
using
a
password
that
contains
the
dollar
sign,
and
you
don't
want
the
expansion
to
happen,
but
this
is
currently
the
default
behavior
that
we
offer
and
while
there's
a
workaround
for
this,
where
you
can
use
two
dollar
signs
to
prevent
expansion,
it's
not
really
intuitive.
B
B
So
in
15.0
we
will
be
validating
the
solution
with
github
users.
We
want
to
see
how
it
works,
how
they
react,
whether
we
can
further
improve
the
ui
copy
and
small
things
like
that,
and
another
issue
that
I
will
be
working
on
is
showing
all
jobs
in
the
pipeline
graph.
Currently,
if
you
have
a
stage
that
has
more
than
100
jobs,
we
only
show
the
first
100
jobs
in
the
pipeline
graph
in
the
pipeline
page.
B
Okay,
my
headphones
connected,
so
yeah
we
will
be
adding
loading
to
the
pipeline
graph
and
finally
showing
all
of
your
jobs.
So
if
you
have
a
stage
with
more
than
100
jobs,
you
will
be
able
to
see
them
all
and
load
them
in
a
way
that
doesn't
affect
the
performance
of
the
pipeline
graph.
B
So
yeah,
if
you
have
any
comments
on
the
problems
that
I've
just
described,
feel
free
to
jump
into
those
issues
and
being
dom,
and
I
or
really
anyone
from
our
team.
If
you
want
to
provide
some
feedback
or
ask
questions
there,.