►
Description
Discuss https://gitlab.com/gitlab-org/gitlab/-/issues/11934
Release:Progressive Delivery
A
Okay,
great
so
today
we
want
to
talk
about
one
of
the
issues
that
we've
been
discussing
for
a
really
long
time,
and
we
have
quite
a
lot
of
community
discussions
there,
which
is
allow
for
pipelines
to
run
an
apparent
project,
and
when
this
originally
it
was
open.
The
idea
there
was
like
a
few
different
use
cases
that
we
wanted
to
solve.
So
like
one
of
the
intended
users
that
is
mentioned
here
is
a
enterprises
are
using
forking
workflow
would
get
lab
some.
B
A
A
But
what
we
did
discuss
Shinya
is
maybe
the
possibility
of
not
working
on
this
original
issue,
but
maybe
swapping
it
with
fetch
sources
from
parent
project.
For
mr
pipelines
and
run
a
merge
result
as
a
first
step,
I
kind
of
wanted
to
I'm
a
little
bit
I
got
a
little
bit
lost
in
all
the
commentary
and
I
just
want
to
make
sure
that
you
know
we're
all
in
the
same
page
and
discuss
the
different
options
that
we
have
to
solve
the
problem.
So.
C
Basically,
this
issue,
you
know
I
created
three
proposals
for
the
original
issue
and
each
each
proposal
has
a
fruit
right
and
yes,
Fitch
sources
from
parent
project
is
one
of
them,
so
we
can
just
ignore
the
decide
issue
and
the
focus
on
this.
These
three
purpose
house,
yeah
by
the
way
I,
have
a
question
for
about
target
the
target
users.
Customers.
C
C
A
C
C
Mm
okay,
so
the
other
question
is:
do
they
use
private
foking,
backflow
or
public
for
kill
box
low
so
like
do
they
that
there's
a
customer,
create
a
public
project
and
then
aim
for
all
developers
to
create
a
fork
project
because
they
don't
wanna
mess
up?
The
original
repository
or
I
know
that
this
is
one
of
the
few
scales
for
this
issue,
and
then
you
know
the
other
opportunities
like
like
us
like
get
lock
it's
open
source
project
and
we
accept
a
lot
of
external
contributors
right
right
and
I.
C
A
C
I
mean
like
before
talking
about
technical
difficulty,
I
think
we
should
talk
about
well
ways
majority,
because
even
if
it's
technically
feasible,
if
the
listeners,
it's
not,
is
minor
the
it
it
doesn't
make
a
lot
sense.
Just
wanted
you
to
make
sure
that
we
really
deal
what
deal
the
building
feature
to
you.
There
muttering.
A
B
Yeah,
that's
a
good
point
supporting
making
it
work.
Forget
lab
users
who
want
to
contribute
to
get
lab
and
supporting
that
workload
doesn't
seem
like
a
nice
place
to
start,
because
we'll
have
a
lot
of
people
who
can
give
us
feedback
quickly
and
that
should
be
pretty
similar.
I
think
the
other.
No,
they
don't
pay
us.
B
So
that's
one
consideration,
but
the
open
source
projects
that
use
it,
who
are
important
in
other
ways
other
than
money
is
is,
is
that
they
also
do
similar
working
similar,
we're
close
to
what
we
do
where
we
have
a
public
project
and
then
you
can
fork
it
to
your
public
project
and
then
because
I
submit
a
merge
request
and
get
it
back
and
so
I
think
that
they
would
want
to
work,
haven't
worked
in
a
very
similar
way.
So
that's
another
plus
the
you
know.
B
Don't
know
really
what
the
differences
are
on
the
back
end
between
supporting
what
that
one
or
the
others,
because
I'm
less
familiar
with
that
workflow
but
I
think
between
those
two.
We
could
start
with
either
one,
but
if
you
know,
if
so,
if
one
of
them
is
way
easier
and
we
can
get
it
working
and
get
it
to
those
users,
then
that
does
make
sense
to
do
that.
But
otherwise
my
preference
would
be
to
do
the
one
that
we
can
test
with
our
own
users.
The
gitlab
contributors
does.
D
Understand
that
reading
from
the
description
that
environments
will
not
be
supportive
to
start
off
from
including
like
project
group,
specific
runners
and
secret
variables,
etcetera
those
all
those
things,
because
if
we
want
to
support
like
our
you
know,
internal
customers,
review
apps
would
be
a
big
part
of
that
and
supporting
the
community
contributors.
It's
a
big
part
of
the
review
flow,
and
is
there
I
mean?
Are
they
like?
What
is
the
extent
of
the
pipeline
that
we
want
to
run
like?
B
B
Would
be
good
to
talk
to
you
about
he's,
worked
on
this
quite
a
lot
and
thought
about
how
he
can
get,
and
he
actually
may
have
the
more
like
internal
perspective.
So
he
has
all
these
special
projects
that
do
things
like
with
the
release.
So
he
wants
developers
to
be
able
to
run
pipelines
in
his
projects
that
that
can
do
certain
things,
but
not
deploy
to
production
right.
But
in
order
to
do
some
of
the
things
they
need
to
do
they
some
of
the
data
that
the
that's
in
his
project.
B
They
don't
need
all
of
it,
but
they
just
need
to
be.
They
need
to
be
able
to
do
things
like
I
can't
even
remember
thought
my
head,
but
I
would
really
set
something
up
to
to
chat
with
him
about
this
flow
as
well
once
he
got
it
a
little
bit
more
started
out
and
I
think
that
that
would
be
an
interesting
way
to
look
at
it
as
well.
B
But
but
to
answer
your
question
to
meet
you
from
my
point
of
view
is
the
yeah
you
you
would
definitely
I
think
eventually
want
to
turn
on
access
to
review
apps.
But
the
thing
that
we
have
to
be
really
careful
about
this
is:
is
unintentionally
exposing
things
and
review.
Apps
need
to
be
able
to
deploy
to
somewhere,
and
so
the
credentials
need
to
be
available
to
the
job.
That
does
that,
which
means
that
somebody
could
try
to
print
them
out
or
email
them
to
themselves
or
something.
A
B
B
The
other
thing
that
that
I
think
is
going
to
be
important
and
you
need
some
way
to
control
what
jobs
run
depending
on
if
you're,
building
a
fork,
so
I
don't
know
if
there
will
be
some
environment
variable
available
or
some
rules
syntax
that
will
be
available.
But
you
should
say
you
know
this
isn't
a
security
thing,
because
somebody
can
change
the
key.
B
B
No
I'm
not
going
to
share
it
because
I
think
I
have
secrets
in
it.
But
it's
just
like
my
notes
on
what
environment
variables
are
available,
including
the
you
know,
actually,
printing
out
from
a
real
pipeline.
What
what
it
looks
like
I'm,
so
I'm
going
to
look
here
and
see
we
have
yeah.
We
have
CI
pipeline
source
which
says
push
right
now
on
a
push,
but
maybe
in
this
case
we
could
set
that
to
fork
or
something
like
that.
And
then
you
could,
you
know,
have
a
rule
on
your
jobs.
B
B
C
C
Like
he
also
pointed
up
the
kind
of
similar
point
that
the
today's
problem
is
that
the
pipeline,
the
configuration
in
parent
project
and
folk
projects
are
very
different,
so
parent
project
users
cannot
trust
the
folk
pipeline
results
because
folk
contributors
can
change
their
paper
and
configuration
to
you
like
something
I,
don't
know
disguise
their
paper.
I
resolve.
C
So
yeah
bet
yes,
so
that's
a
totally
legitimate
point
and
yeah
the
purple
site
said
like
let's
try
to
make
a
pipeline
parent
project
instead
of
for
project
right
and
then
also
that
comes
with
security
concerns
that
I
don't
want
to
expose.
All
of
the
resources
belong
to
parent
project,
for
example
clusters.
C
A
C
Think
it's
it's
basically
like
taking
it
out
of
one
page
between
them
like
the
pineapple
meet
the
pineapple
is
basically
it
doesn't
allow
for
external
concrete
contributors
to
create
pipeline
in
parent
by
default.
It
doesn't
allow,
but
parent
project
members
can
allow
can
create
pipelines
instead
of
them
as
a
behalf
of
them.
C
So
at
first
external
contributors
going
to
use,
submit
their
markets
to
a
parent
project
right
and
the
imperative
project
members
going
to
examine
it
and
then
at
first
they
do
code
review
and
they
make
sure
that
they
know
like
a
mother's
car,
in
matter,
weakness
like
trying
steal
secrets
from
parent
project
etc
and
after
the
maintainer
impairing
the
project,
make
sure
that
they
click
a
button
like
a
run
pipeline
button.
Today
you
can
see
in
much
we
get
stopped
so
the
pipeline
tab
in
Marcos
and
when
they
click
the
button
it
actually
creates.
B
You
get
a
lot
right,
that's
nice,
because
it
then
runs
as
the
user
who
clicks
on
the
button,
which
is
super
super
clear
and
there's
no
magic
happening
there.
It
also
gives
you
a
chance
to
say
like.
Is
this
some
malicious
thing
and
that's
good?
The
downside,
of
course,
is
that
some
poor
person
has
to
go
click
on
all
of
these
things.
C
D
B
B
D
B
D
So
the
the
thing
that
I
will
foresee,
because
I'm
I'm
in
favor
of
allowing
us
to
do
that
so,
for
example,
say
that
if
mini-cons
really
comes
in
I
see
that
they're
pushed
in
the
code,
I
see
it's
a
CSS
change.
I
know
and,
like
seems
like
a
good
thing
like
hey
I,
want
to
see.
If
this
will
run
the
review
up,
I
push
for
the
pipeline
to
be
run.
B
A
B
C
I
almost
forgot
what
I
wrote,
but
it's
basically
like
either
side
like
exposing
like
it's
automatic
but
allowing
for
contributors
to
access
everything
and
then,
like
the
other
one.
The
second
proposal
is
it's
kind
of
this
kind
of
line.
Yes,
like
it's
more
like
automatic
way,
but
we
have
to
build
like
security
gates
at
first
otherwise,
parent
parent
resources
going
to
bubble.
So
if
we
go
down
this
path,
we
have
maybe
we
need
more
iterations
to
see
the
body
to
users,
because
you
know
we
didn't
I.
A
Yeah,
and
also
it's
in
terms
of
explicitly
enabling
each
resource,
we
need
to
create
this
huge
list
of
stuff
that
I
think
it's
unknown
at
the
moment.
But
I
assume
this
can
be
pretty
large
and
would
also
require
us
to
design
a
setting
that
has
like
this
huge
list
of
feature
or
the
resources,
the
project
resources.
And
then
you
know
you
need
to
check
or
uncheck
whatever
resource,
and
this
can
be
rather
large
and
wouldn't
need
pagination,
or
you
know
some
kind
of
option
to
sort
and
filter
and
just
to
make
it
usable,
I.
Think.