►
From YouTube: Compliance Pipeline Configuration Proposal
Description
A summary of the proposal in https://gitlab.com/groups/gitlab-org/-/epics/3156 to provide background on the proposal and how various issues fit together.
A
A
Okay,
so
this
is
the
very
lengthy
and
complex
epic
that
we
started
off
with.
But
to
summarize,
what
we'd
like
to
achieve
is
the
ability
for
a
regulated
enterprise
compliance
team
to
create
a
compliance
pipeline,
configuration
in
some
group
and
project
that
they
control,
which
helps
with
separation
of
duties,
helps
with
the
general
control
of
that
configuration
and
gives
them
the
reassurances.
A
So
this
compliance
team
creates
that
compliance
configuration
and
we'll
call
it
group
a
compliance
project.
A
the
developer
then
creates
their
own
local
configuration
in
we'll
call
it
group
b,
developer
project
b
and
through
the
use
of
our
custom
compliance
labels,
which
I'll
come
back
to
here
in
a
second
they'll,
be
able
the
the
group
owners
of
this
group.
For
now,
I
will
be
able
to
specify
this
compliance
pipeline
configuration
location,
and
so
what
happens
is
when
the
developer
wants
to
make
a
change
they're
at
run
time.
A
Their
pipeline
will
combine
both
this
compliance
configuration
and
their
local
configuration,
and
so
the
the
dynamics
that
exist
there
took
me
some
time
to
wrap
my
head
around,
and
so
I
had
somewhat
of
an
epiphany
today,
thanks
to
tim
poffenbarger,
and
so
I
wanted
to
share
that
in
particular,
as
we
embark
on
one
of
the
issues.
That's
part
of
this
epic
in
the
compliance
group,
so
to
touch
on
how
this
will
link
together
the
the
use
of
our
compliance
labels,
which
we're
in
the
process
of
evolving
to
be
customizable
in
part.
A
So
for
the
sake
of
simplicity,
let's
say
that
that
is
the
project
I'm
going
to
apply
this
label
to
well,
once
that's
applied,
we'll
have
this
read-only
field
that
shows
to
the
project
maintainer
or
anyone
else
who
has
view
rights
to
this.
Here
is
a
location
where
this
mandatory
include
exists.
It
is
often
this
other
group
in
this
other
project
maintained
by
some
other
team.
Now
this
is
all
well
and
known
and
understood
by
our
customers,
users,
and
so
I
don't,
I
don't
think,
there's
any
issue
there.
A
A
The
other
things
that
are
the
other
issues
that
we
have
to
tackle
are
making
sure
that
we
support
variables
in
the
include
section
of
ciamelconfig
and
that's
in
reference
to
this
key
here,
where
we
can
include
other
files
into
the
the
configuration
so
right
now
that's
not
supported
and
would
have
to
be.
I
believe
jackie
porter's
group
is
working
on
refining
this
to
then
implement,
so
we're
collaborating
with
them.
A
So
I
think
we
may
not
need
to
to
deal
with
that
for
now,
but
the
second,
the
follow-up
to
that
is
in
creating
this
new
variable.
Sorry,
let
me
back
up
for
a
second,
so
in
the
include.
We
want
to
be
able
to
support
these
variables,
so
that's
step
one
just
having
the
support
in
general,
but
step
two
is
in
making
sure
that
we
have
this
additional
variable
that
does
not
yet
exist
today.
A
A
A
How
those
files
are
combined
like
that
that
was
basically
just
magic
as
far
as
I
was
concerned,
so
I
had
a
great
conversation
with
him
and
he
walked
me
through
the
dynamics
which
I
think
are
really
helpful
to
understand,
especially
as
we
look
to
tackle
one
of
those
ci
issues
so
in
our
compliance
yaml.
Let's
say
that
we've
defined
this
really
basic
configuration,
we've
defined
a
global
variables
key
and
we
have
the
include
just
ignore
this
syntax
for
now.
Just
assume
that
we're
using
one
from
from
the
proposal.
A
A
Well,
we
spent
up
a
project
and
in
that
project
we
defined
this
really
simple,
gitlab
ci
haml
file.
So
in
here
we
defined
this
sas
job.
That
can
that
I
don't
want
to
say
conflicts,
but
is
duplicative
of
the
compliance
one,
so
the
compliance
one.
You
can
see
it's
fairly
simple.
We
have
the
sas
far
up
in
variables.
We,
I
believe,
the
default
stage
for
this
is
test,
and
then
we
defined
some
really
basic
script
that
just
prints
out
the
statement
of
running
that
global
variable.
A
Well,
when
the
local
project,
the
developer,
creates
a
yaml
file
if
they
explicitly
define
this
variables
key,
or
this
variable
section
with
a
sas
var
key
and
value
of
this
string
here,
it
is
being
explicitly
defined
as
part
of
that
job
and
they're
also
explicitly
defining
the
build
stage
for
this
job.
So
when
these
two
files
are
combined,
my
understanding
of
what
happens
is
we're
now
left
with
this
combined
yml
file,
the
global
variables
section,
the
the
stages
that
were
defined,
but
then
in
the
sas
job.
A
We
see
this
explicitly
defined
sas
far,
which
will
take
precedence
over
the
global
one,
as
I
understand
it,
and
the
stage
being
explicitly
defined
means
this
will
no
longer
run
a
test.
This
will
run
in
the
build
stage,
but
you
see
that
the
script
remains
the
same
as
what
was
in
the
compliance
definition.
A
So
that's
where
we
are
today.
My
understanding
is
that,
although
this
is
a
an
odd
behavior
in
terms
of
this
particular
use
case
or
problem
space,
it
is
workable
to
say
that
if
you
do
not
want
this
behavior
to
exist,
then
you
should
be
explicitly
defining
these
keys
and
values
as
part
of
your
job
definitions,
which
I
believe
is
considered
best
practice
anyway.
So
just
want
you
all
to
be
aware
of
that
and,
as
a
somewhat
related
note
I'll
go
back
to
sharing
this
other
screen.
A
One
of
the
concerns
that
had
originally
arisen
as
part
of
the
force
includes
paradigm
was
this
idea
that
developers
had
no
possible
way
to
circumvent
this
process
in
the
event
of
an
emergency.
We
don't
want
our
customers
to
have
a
production
environment
that
stays
down
because
they
can't
go
in
and
fix
something
because
of
this
compliance
pipeline
configuration
that's
trying
to
control.
A
So
what
we're
providing
is
a
very
simple,
intuitive
and
native
way
for
them
to
achieve
that
outcome
without
having
to
go
and
disable
a
bunch
of
settings
or
tweak
a
bunch
of
things
to
be
able
to
then
merge
this
change
and
then
make
sure
they
go
back
and
re-enable
all
of
those
standard
settings
or
configurations
and
as
another
part
of
this
is
we'll
be
able
to
then
document
things
like
who
requested
this
bypass
and
merge.
Why
was
it
requested?
A
A
So
this
is
the
escape
patch
that
I
think
we
can
continue
to
iterate
on
that
provides
developers,
an
ability
to
bypass
and
merge.
Even
though
this
compliance
pipeline
exists
because
that
type
of
action
should
be
a
fairly
infrequent,
as
has
been
confirmed
by
the
customers,
we've
spoken
with
about
these
solutions
or
proposals
rather,
but
it
should
also
be
making
easier
a
process
that
already
exists,
but
now
we're
supporting
it
natively
within
gitlab.
A
So
hopefully,
this
was
helpful
and
informative
from
a
context
perspective
and
background
on
this
larger
compliance
pipeline
configuration
initiative
and
also
giving
some
background
to
some
other
issues
that
we're
working
on
that
may
not
have
made
as
much
sense
without
this
particular
presentation.
So
let
me
know
if
you
have
any
comments
or
feedback
in
any
of
those
issues
or
in
slack
and
thanks
for
watching.