►
From YouTube: PE sync: CI_JOB_TOKEN at group level
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
Is
the
23rd
of
november,
and
today
we
are
discussing
the
proposal
for
the
issue,
configure
job
token
scope
at
group
level
just
to
provide
a
context
that
we
enabled
this
capability
at
project
level
that
we
provide
users
with
this
option
to
secure
their
ci
job
token,
and
we
want
to
move
this
level
up
to
at
group
level.
A
So
that,
like
when
organizations
which
work
with
groups
have
a
lot
of
projects
under
groups
or
sub
groups,
it
would
be
very
tedious
for
them
to
go
around
and,
like
individually
change,
the
settings
for
each
one
of
them.
So
something
that
is
maybe
at
the
root
level
is
what
we're
exploring
all
right.
Then.
Moving
on
to
our
questions,
yeah
fabio,
what
are
your
views
with
how
the
conversation
has
evolved?.
C
Sorry,
I
was
just
double
checking
where
we
were
at
with
the
comments
on
the
issue:
okay,.
A
So
the
latest
proposal
is
adding
alerts
on
adding
alerts
that
communicate
to
user.
If
any
change
has
been
so,
let's
say:
if,
if
we
are
going
with
making
it
a
route
level
feature,
then
what
would
happen
at
project
level
and
where
it
is
that
we
should
notify
users
that
something
has
been
enforced
at
truth
level,
and
this
is
the
impact
that
it
would
have
on
your
configurations
for
this
project.
C
C
C
I
know
I'm
I'm
assuming
that
if
now
suddenly,
we
want
to,
you
know,
put
this
feature,
and
if
we
want
to
limit
the
ci
job
token
scope,
we
would
have
a
maintainer
that
is
decides
to
enable
this
for
gitlab
org
top
level.
Pro
top
level
group
will
first
communicate
with
everybody
says
like
we
are
going
to
enable
this
to
this
day.
So
if
you're
gonna
get
any
errors
related
permission,
you
know
it
might
be
related
to
this.
At
least
I
see
how
how
I
see
this
working,
but
in
order
to.
C
Alert
for
a
specific
project
to
say
that,
suddenly
something
has
changed,
the
permission
and
I'm
wondering
how
we
could
implement
something
like
that,
because
what
we
are
changing
is
with
the
ci
job
token
scope.
Is
we
added
another
filter
in
the
our
permission
policies,
so
an
action
that
was
allowed
suddenly
becomes
a
disallowed,
but
it's
not
like
a
check
that
we
perform
after
the
permission
policy
so
where
we
could
say
it
failed
because
of
this
reason,
in
order
to
understand
why
it
failed,
like
you
know,
in
order
to
debug,
why
fail?
C
We
will
need
to
debug
the
policy,
the
the
permission
policy
and
then
to
understand
which
rule
actually
failed.
In
that
case,
we
will
figure
out.
Okay
failed
because
of
the
ci
job.
Token
scope
decides
to
disallow
this
action,
but
it's
not.
It
would
not
be
able
to
easily
provide
like
a
an
error
message
to
say:
oh
failed,
because
of
this
reason,
unless
we
have
we
hook
into
our
permission
policy
and.
C
I'm
trying
to
figure
out
like
how
we
would
implement
something
like
that
because
it
it
it
it
will.
Look
like
the
user
is
not
a
member
of
that
project
when
the
ci
job
token
is
not
allowed
to
access
the
target
project,
and
this
is
why
they
are
getting
either
401
unauthorized
or
they
might
get
forbidden
depending
on
the
end
point.
But
it
looks
like
you're,
not
a
member
or
you
don't
have
either
like
enough
permission
to
do
to
perform
this
action
or
you're,
not
a
member
of
that
project.
C
Yeah,
because
the
filtering
of
the
ci
job
token
scope
happens
before
even
we
run
other
permission
checks
like.
Can
I
actually
read
a
repository?
It
will
be
more
like
if
you,
if
you're
trying
to
access
a
project
that
is
not
in
the
scope,
we
don't
even
go
further
to
check.
Whether
do
you
actually
have
that
permission
so
that
basically
forbid
everything
like
you
are
not
a
member
of
that
project.
C
Well,
it
depends
what
we're
trying
to
do
with
the
cia
job
token.
If
you're
trying
to
use
this
edge
of
token
to
trigger
a
pipeline,
you
will
get
like
probably
four
or
four
or
four
errors
that
that
project
doesn't
even
exist.
The
project
where
you
want
to
run
the
pipeline
doesn't
exist
and
you
can
you
might
get
something
like
that
or
if
you're
trying
to
use
a
job
token
to
download
a
package,
you
might
get
the
same
error.
Let's
say
that
project
you're
trying
to
download
the
package
from
doesn't
exist.
C
A
Okay,
so
that
means
that
the
number
of
use
cases
like
in
ways
in
which
the
projects
would
be
affected-
it's
very
wide.
So
it's
not
that
that,
which
is
one
kind
of
error
for
which
we
can
provide
in
the
the
number
of
cases,
could
be
verified
depending
on
what
we
are
trying
to
use
the
ci
job
token
for
in
the
configuration
yes.
C
Yes,
and
also
the
the
error
would
be
different
depending
on
what
and
how
the
the
end
point
trades.
C
When
you
don't
have
permission
to
perform
that
action,
some
end
points
marathon,
404
some
returns.
My
return
401
another
rise,
some
other
endpoints
return
for
three
forbidden,
so
that
depends
on
how
the
the
endpoint
is
configured.
But
basically,
when
the
permission,
when
you
don't
have
permission,
we
raise
an
exception
that
is
kind
of
return
that
way,
so
that
will
be
an
equivalent,
as
you
are
not
a
member
of
that
project,
and
so
you
will
be
that's
why
it's
difficult
to
distinguish.
C
You
don't
have
access
to
this
because
you're,
not
member
or
because
you
can
see
a
job
token
is
configured
differently
and
in
our
troubleshooting
guide
about
the
ci
given
in
the
edge
of
token
we
do
have.
We
do
list
different
error,
error
messages,
because
each
and
the
point
might
treat
it
differently
and
see.
If
I
find
that
I
think
there
is
some
kind
of
hack
we
could
do
to
catch
that,
but
I'm
wondering
whether
we
want
to
go
on
that
route
and
whether
it
is
needed.
C
Actually
this
this
different
three
that's
an
example
of
return
of
four
or
four,
but
you
can
see.
The
error
is
different,
because
each
endpoint
would
return
a
different
error
messages,
and
so
you
will.
You
will
get
like
an
error
like
this.
A
Okay,
so
I
have
a
take
on
this
so
right
now.
The
proposal
that
I
shared
was
keeping
in
mind
sasha
and
devon.
I
also
mentioned
that,
but
it
seems
like
if
a
group
a
root
level
change
if
a
root
level
policy
would
be
implemented,
it
would
be
more
like
the
organization
wants
to
function.
This
way
and
the
persona
that
should
be
associated
with
this
is
very
different,
so
I
should
be
focusing
on
sasha,
let's
say
because
this
has
more
to
do
with
the
admits
and
at
the
most
devops
engineer.
A
That
means
we
don't
have
to
like,
let
the
developers
know
what's
going
on,
but
in
fact
it's
something
that
has
been
decided
for
the
organization
that
these
are
the
projects
that
should
be
accessed,
and
these
are
the
ones
and
the
rest
should
not
be,
and
that's
it.
C
C
Token
scope,
unless
we
enable
it
first,
and
so
this
is
kind
of
why
you
actually
might
need
to
fix
that
might
be
kind
of
a
way
to
help
users
to
deal
with
with
enabling
the
ci
job
token
scope,
because
as
soon
as
you
enable
it
to
start
blocking
any
requests
outside
the
the
project,
and
then
you
can
add
the
the
projects
to
the
scope.
So
then
those
requests
wouldn't
be
allowed.
But
there's
like
a
period
that
you
first
need
to
enable.
C
Then
that
can
might
start
blocking
pipeline
some
some
jobs
and
that
will
you
can
get
like
pipeline
failures
and
then,
as
you
start,
adding
job
the
projects,
things
could
kind
of
start
succeeding
again.
C
C
So
if
you
have
a
running
pipeline
that
you
was
configured
to
use
the
job
token
to
download
the
package
from
somewhere
else
and
the
moment
you
enable
the
ci
job
token
scope
that
will
block
any
request
to
another
project,
so
any
some
running
pipeline
might
fail
because
of
that,
because
there
is
no
way
of
enabling
the
of
adding
a
project
before
enabling
the
the
edge
of
token
scope.
C
So,
ideally,
we
would
like
to
have
like
if
I
were
like
a
group
owner
like
or
like
a
maintainer,
that
I
would
like
to
administrate
this
job
token.
I
will
first
collect
all
the
requirements
understand
all
where
the
ch
of
token
is
used.
What
is
used
for,
and
then
say,
okay,
it's
used
to
access
this
project,
this
other
project,
this
other
project-
I
add
them
all
to
the
scope
and
then
enable
the
scope.
C
So
then,
all
the
all
the
permissions
are
configured
and
the
cajon
token
has
already
access
to
everything
he
needs
and
nothing
else.
But
today
we
will.
We
have
this
kind
of
pro
ux
program.
You
first
need
to
enable
and
then
you
need
to
configure
it.
You
might
have
like
a
failing
pipelines
there,
and
so
I'm
wondering
by
you
like
improving
this
ux.
B
C
Er
maintainers,
obviously
a
configuration
the
scenarios
to
to
use
a
different
strategy
that
is
not
not
blocker
or
like
at
least
not
not.
As
this
group
to
say
you
know,
things
start
to
fail
first
before
we
we
go
and
fix
them,
and
that
might
be
a
way
of
not
dealing
with
specific
error
messages.
I'm
wondering
about
that
and.
B
So
basically,
the
main
thing
is
that
the
interface
for
adding
projects
is
hidden
right,
and
so,
if
we
just
keep
it
always
visible,
that
seems
to
be
a
pretty
simple
solution.
Assuming
we
can
flip
it
back
and
forth
and
just
leave
it
visible
it.
It
sounds
like
a
good
and
I
didn't
even
think
of
it
until
you
mentioned
it
right
now.
It's
like
oh
yeah,
because
it's
a
firewall
that
you
you're,
locking
down
everything
and
you're
poking
holes,
but
you
actually
wanted
to
find
those
holes
before
you
you.
You
know
you.
D
D
So
the
the
concern-
the
use
case
that
we're
talking
through
is
that
if
I'm
a
group
admin,
I'm
still
trying
to
write
my
head
a
little
better
with
a
ci
job
token.
I
enable
this
feature-
and
I
say
I
this
is
enabled
now
for
my
group
and
all
of
my
projects
within
it.
I'm
going
to
give
global
access
to
all
of
the
projects
within
the
group,
so
they
can
access
each
other
with
this
ci
job
token
and
it's
secure.
So
it's
kind
of
has
that
limited
life.
D
But
then,
if
other
stuff
wants
to
call
into
my
project,
I
need
to
specifically
allow
it.
What
we
want
to
then
alert
is
that
that
someone
calling
from
that
other
project
that
maybe
previously
had
access
now
they
understand
why
their
pipeline
is
failing,
because
they
don't
have
a
token
that
can
access
this
project
or
projects
within
this
group.
D
That's
the
problem
we're
trying
to
solve
it's
just
to
make
sure
I
crack
everything
here.
D
So
have
we
handled
that?
I
mean
we
have
that
problem
today
at
the
project
level,
because
we've
enabled
this
at
the
project
level.
Do
we
have
alerting
for
this
the
project
level
do
we
know
this
is
a
problem
with
the
project
level
today,
or
are
we
trying
to
solve
a
problem
that
doesn't
actually
exist.
C
So
today,
it's
disabled
by
default
at
project
11.,
so
that
means
that
the
ci
job
token
has
the
same
permission
as
the
user
in
person.
Okay,
the
the
ci
job
token.
So
there
is
no
restriction
in
that
case
so,
but
we
have
seen
that
I
don't
know
like
how
many
top
level
groups
we
have.
I
think
I
pulled
some
information
there
before
but
like
we
have.
C
C
Configured
links
between
between
projects-
and
I
don't
know
this-
is
how
many
customers
like
or
like
a
top
level
organization
that
will
be
equivalent
to,
but
but
basically
we
have
some.
C
But
if
something
gets
configured
to
allow
so
to
access
something
external,
it
won't
what
happened,
and
so
the
job
basically
will
fail.
D
D
D
Even
if
we
don't
yeah,
if
we
don't
hook
the
permission
model
and
just
say,
there's
a
lot
of
reasons,
the
job
could
fail.
Here's
one
of
them
and
give
you
a
very
short
list
or
link
you
to
documentation
that
could
take
you
down
that
path
of
yeah.
Any
number
of
things
could
have
failed.
One
of
them
could
be
that
you're
you're
just
not
allowed,
because
they've
enabled
the
the
restricted
cia
john
tokens.
C
Yeah
and-
and
this
is
like
this
depends
on
how
the
each
endpoint
surface
permission
errors,
because
what
we
are
doing
with
the
siege
of
token
scope.
It's
very
it's
a
very
low
level.
D
D
D
If
it's
really
only
three
percent
of
cases
that
we
think
are
three
percent
of
the
known
projects
that
are
going
to
have
a
problem
like
this,
where
they
would
benefit
from
surfacing
the
error.
I
don't
think
that
we
gain
a
lot
by
investing
the
time
to
hook
the
permission
model
and
try
to
surface
a
very
descriptive
error
to
them.
I
think
we're
better
off
with
investing
a
little
bit
of
time
and
documentation,
saying
hey,
there's
a
lot
of
reasons
the
pipelines
fail
here.
Here's
the
troubleshooting
guide.
C
Yeah,
this
is
basically
why
we,
okay,
our
first
iteration,
was
let's
list
some
examples
of
why
how
this
can
fail,
and
we
put
in
our
stage
of
token
troubleshooting
guide,
or
at
least
people
can
search
for
that
error
and
find
that
there
is
a
reason
why
this
might
fail,
and
that
was
our
first
iteration.
But
the
next
iteration
might
be
to
refine
error
messages
and
our
api
endpoints,
but
that
can
be.
C
To
do
that,
it
means
that
every
pipeline
and
every
api
endpoint
will
return
a
more
specific
error
and
today,
like
packages,
might
return
a
specific
error
message
and
when
using
no.
No,
not
necessarily
when
you
see
ci
job
talking
about
when
you
don't
have
permission
to
do.
B
Scope
can
be
one
of
the
reasons,
so
I'm
just
like
wondering
for
the
three
examples
in
the
doc,
for
example,
which
part
of
these
would
we
be
able
to
to
adjust,
for
example,
because
like
if
we're,
if
we're
just
returning
an
error
code,
four
or
four
like
it's,
it's
going
to
be
hard
to
tweak
that
isn't
it
or
are
we
like
in
the
second
one
we
have
air
error4
not
found
like
that's
kind
of
a
standard
thing
like?
Are
we
able
to
edit
that
not
found
and
then
add
a
long
message
after
that.
C
C
C
D
A
I
think
we
should
summarize
this
and
take
it
async,
because
I
still
don't
have
a
very
conclusive
answer
to
what
should
be
the
next
step.
Okay,.
C
Does
it
make
sense
to
after
we
fix
the
ux,
where
we
allow
the
ch
of
token
to
be
first
configured
before
we
we
enable
it
are,
we
does
it
make
sense.
The
proposal
of
start
with
the
root
level
settings
rather
than
using
group.
B
A
I
think
it
does
just
one
question
that
if
we
are
going
to
reverse
the
workflow,
not
reverse,
I
mean
if
we
are
going
to
go
with
implementing
this
method
in
the
workflow.
Should
that
not
also
reflect
on
the
project
side.
A
So
we
would,
since
that
one
is
already
in
place.
We
can
start
off
working
on
this
with
a
different
workflow
and
then
create
an
issue
to
change
the
other
one.
That
sounds
fine.
C
B
Question
it,
it
was
just.
It
was
a
bit
confusing
to
me
how
how
the
the
top
level,
the
the
group
level,
if
you
enable
it-
and
you
also
have
things-
enabled
at
the
project
level
how
those
would
interact
so
like
if
you
turn
it
on
at
the
group
level,
say
only
projects
within
this
group
can
talk
to
each
other
in
a
sense
and
then
in
the
in
the
project
settings.
You
then
sp
specify
a
project
outside
of
the
group
like
where
what
would
the
precedence
be.
A
A
I
mean
we
should
not
take
away
the
existing
connections
with
the
other
projects,
but
just
enforce
the
new
ones
like
something
that
has
been
added
manually
to
the
list
should
stay
there,
but
on
top
of
that
it
should
get
access
to
everything
else
in
the
project.
A
C
C
If
a
project
level,
a
group
level
you
can
enable
enable
it
and
by
default
that
will
give
access
to
all
the
projects
within
the
same
top
level
group,
and
so
that
means
yeah
in
the
case
of
gitlab
or
any
project
on
the
gitlab.org
can
allow
you
can
access
any
other
projects
within
the
gitlab
work
as
long
as
the
user
has
access
to
it.
C
But
then,
if
gitlab.org
gitlab
will
specify
an
external
projects
tool
that
needs
to
access,
we
still
kind
of
we
make.
We
basically
create
like
a
sum
of
all
the
all
the
scope
and
allow
that
to
the
approach
to
specify
something
outside,
and
I
think
we
need
to
kind
of
balance.
C
What
is
lucky
pros
and
cons
in
this
slightly
and
it's
what
a
top-level
kind
of
organization
from
from
compliance
perspective
or
whatever
or
security
permission
perspective
would
want,
or
they
would
want
to
instead
to
configure
everything
at
up
level
and
to
be
more
secure
and
not
allow
projects
to
specify
their
own
and
their
own
scope.
I'm
not
I'm
not
sure.
I
think
this
is
something
we
will
need
to
maybe
get
feedback
from
users,
or
I.
C
D
Maybe
we
start
in
a
really
simple
way:
if
you
can't
get
yourself
into
a
weird
security,
bind
where
things
conflict
or
we're
very
explicit
about,
when
you
add
these
things,
it
cascades
to
projects,
or
vice
versa-
I'll
spend
some
time
needling
on
this,
while
I'm
trying
to
digest
turkey
this
week
and
put
some
thoughts
back
in
on
friday
or
on
next
monday,
rather
and
we'll
be
on
on
friday
cool.
D
This
is
really
helpful
and
just
me
trying
to
get
my
brain
around
what
the
ci
job
token
does
and
how,
like
you,
enable
it
and
this
so
thank
you
for
this
30
minutes.
For
me,
I
appreciate
it.
I
have
to
drop
off
and
go
drop
the
kid
off
at
school,
but
I
did
want.
B
It's
been
two
years,
I
see
your
name
all
the
time
and
when
I
saw
you
when
I
saw
you
show
up
in
the
video
it's
like,
oh
my
god.
Finally,
it's
happened.