►
From YouTube: Stumble-through of Confidential Merge Requests
Description
Looking in to the workflow for confidential merge requests (https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html#merge-requests-for-confidential-issues) in GitLab and getting a sense for how the forking aspects work to actually have that private project.
The process doesn't feel as smooth as it should be the first time through, but it seems like once the private project exists it should be workable.
A
So
there's
a
issue
put
in
about
sort
of
a
workflow
being
unclear
for
confidential
merge
requests,
and
I
thought
this
would
be
a
good
way
for
me
to
spend
some
time
playing
with
confidential,
merge
requests
and
making
sure
that
we
can
clean
up
those
docs
and
make
them
better.
So
I'm
going
to
share
my
screen
to
sort
of
walk
through
the
docs
and
the
way
I
interpret
them
currently
and
sort
of
what
we
expect
the
workflow
to
be
inside
of
a
group.
A
I'm
also
the
owner
here
so
like
I've
got
some
some
slightly
elevated
permissions,
but
permissions
that
would
you
had
sort
of
all
of
these.
You
could
get
down
this
path,
so
public
project
and
then
inside
of
my
public
project.
I've
got
a
confidential
issue,
so
we
would
consider
this
to
be
a.
You
know,
something
that
we
don't
want
displayed
in
our
public
group
in
our
public
project.
We're
trying
to
hide
this,
probably
a
security
issue
that
we
want
to
fix.
A
A
A
All
inside
of
there
named
everything
in
our
confidential
issue,
because
we
don't
want
to
work
on
the
confidential
issue
and
have
a
merge
request.
That
would
be
visible
publicly,
because
this
is
a
public
project
and
so
people
would
be
able
to
see
the
commits
and
see
what
we're
trying
to
fix
prior
to
that
fix
being
available
and
deployed
in
the
application.
A
What
that
means
is
we
now
have
we
need
to
do
this
somewhere
else,
and
so
the
the
process
in
gitlab
is
that
you
do
this
in
a
private
project,
a
fork.
It's
a
private
fork.
You
do
the
merge
request
there,
you
get
it
completely
reviewed
merged
into
the
default
branch
of
that
project
and
once
everything's,
ready
and
you're
ready
to
cut
a
release
on
your
main
project,
you
would
go
and
you
create
a
merge
request
that
targets
your
confidence
or
your
private
fork
into
your
public
project.
A
Get
that
merge
doesn't
need
another
review
because
that's
already
happened
and
then
you
tag
your
release
and
you're
good
to
go.
So
let's
make
sure
that
works
out.
So
let's
create
a
confidential
merge
request,
and
so
this
is
saying,
create
a
confidential,
merge,
request
and
branch,
there's
no
project,
so
no
forks
are
available
to
you.
This
projects
issue
is
confidential,
fork
the
project
and
set
the
forks
visibility
to
private.
A
A
A
A
A
A
A
A
A
So
if
we
do
this
now
in
our
private
project,
our
security
project,
this
project-
here's
the
merge
request,
so
this
is
essentially
private
because
of
the
parent
permissions
of
the
project.
So
I
think
the
piece
that's
probably
broken
here
is
that
you've
got
to
do
this
in
a
subgroup,
and
I
don't
know
if
that's
a
change.
A
A
workflow
that
we
don't
allow
you
to
create
a
duplicate
project
in
the
namespace
that
probably
makes
sense.
You'd
have
to
have
a
different
name
for
the
slug,
so
doing
it
in
a
subgroup
makes
the
most
sense.
So
we
should
probably
just
clean
up
the
docs
and
say
there
needs
to
be
a
subgroup
to
do
this.
A
But
that
covers
off
on
the
inheritance
piece
and
make
sure
you've
got
the
permissions
assuming
everyone.
That's
a
member
of
the
parent
project
and
group
flows
down
that
works
there,
and
then
you
can
go
through
that
process.
So
it's
really
like
that.
First
piece
of
getting
that
security
project
set
up
is
probably
the
the
painful
piece
and
then
once
that
is
done,
it'd
be
relatively
easy.
Probably
to
keep
this
project
up
to
date.