►
From YouTube: Tan & Matt: Impromptu Brainstorm
Description
A discussion about settings inheritance and a few other related feature ideas for the Compliance group at GitLab.
B
B
Yeah,
so
we
so
we
implemented
that
feature
and
the
intent
there
was:
let's
give
customers
a
way
to
label
the
projects
that
they
care
about,
like
in
a
compliance
context,
so
that
we
could
then
have
flexibility
like
what
you
did
with
the
instance
level.
Merge
request
approval
rules
where
we
say
apply
this
disruptive
policy
only
to
regulated
projects,
so
that
worked
great.
We
got
really
positive
feedback
from
that,
but
then
we
had
follow-up
feedback.
B
That
said,
basically,
oh,
this
is
great,
but
I
also
want
to
be
able
to
label
projects,
as
maybe
having
specific
environments
like
aws
or
google
cloud.
Maybe
I
want
to
label
specific
things
like.
Oh,
this
is
a
linux
application
or
like
a
linux
environment
versus
windows,
and
so
we
got
into
the
topic
of
like
well.
We
have
project
topics,
and
maybe
we
just
iterate
on
that
to
improve
that
feature.
B
But
then
there
was
this
overlapping
effort
where
the
compliance
pipeline
configuration
we'll
call
it
initiative,
and
the
recent
proposal
basically
says
as
part
of
the
as
part
of
the
solution
use.
Custom,
ci
configuration
path.
Well,
one
of
sid's
main
concerns
was
we
don't
want
this
to
apply
broadly.
This
should
be
refined
in
some
way
that
it's
as
least
disruptive
as
possible,
and
so
it
felt
like
those
two
went
hand
in
hand.
B
I
don't
think
we've
come
back
to
it
just
yet,
but
the
the
reason
that
custom
ci
config
path
is
there
is
because
we
thought
well
if
they
want
to
define
hipaa
and
so
to
avoid
a
breaking
change.
We
could
say:
take
those
five
hard-coded
framework
labels
that
we
added
and
just
make
them
editable
as
part
of
this
customizable
area
and
add
an
optional
field
for
custom
skypath,
and
so
every
project
that
you
label
with
socks.
B
For
example,
if
you
define
a
custom
ci
path
to
like
tans
group,
slash
tans
project,
slash
tan.gillabsci.yaml,
then
every
project
with
that
label
would
call
out
to
that
external
or
that
custom
ci
path
in,
in
addition
to
their
local
yaml
file
and
the
thinking
there
was
in
that
tan
gitlab
ci,
which
is
outside
of
the
local
project
being
controlled
by
the
compliance
team.
You
could
specify
different
rule
sets
to
say,
run
this
rule
set
for
this
project
name
space
and
this
rule
set
for
this
or
or
label.
A
B
I
think
the
reason
I
mentioned
it
in
that
group
level
merge
request.
Approval
rules
is
because
we
were
talking
about
the,
I
guess,
the
inheritance
pattern
and
how
we
built
it
for
the
instance
level,
merger
quest
approval
rules
or
settings.
I
should
say-
and
so
I
I
think
I
was
raising
that
issue
for
your
awareness
to
say,
hey,
like
maybe
there's
some
way
we
can
leverage
these
labels
in
conjunction
with
that
inheritance
model
or
to
supplant
that
inheritance
model
with
something
different
based
on
the
new
criteria
we've
been
given
around
hey.
B
A
Yeah
yeah,
I
can,
we
can
see
the
motivation
behind
label
as
well
together.
It
gives
a
little
bit
more
flexibility,
but
also
you
know,
I
think
I
can
think
of
it
path
here,
where
one
that
we're
talking
about
is
recording
what
almost
like,
what
the
the
metadata
that
the
compliance
framework
have
or
a
label
or
compliance
label
can
have,
and
the
other
part
was
applying
those
rules
to
other
areas
like
whether
that's
going
to
be
saying
you
know
mr
approvals
or
push
rules,
and
things
like
that.
A
A
The
group
level
much
request
approval
rules
are
on
the
application
path,
taking
the
data
that
we
recorded
that
attached
to
the
labels
or
compliant
labels
and
then
apply
it
here,
so
they
yeah
they're
they're,
actually
contributing
to
the
end
user.
Experience
of
of
having
this
apply
or
inheritance
gone
through,
but
that's,
I
think,
that's
the
two
different
different
problems
that
we're
trying
to
kind
of
tackle.
A
B
When
you
you
raise
a
another
point
that
I
forgot
to
mention,
one
of
the
reasons
I
brought
this
up
was
because
the
paradigm
of
toggle
something
and
then
enforce
it
only
the
compliance
labeled
projects
right
now
would
be
really
ugly,
because
we'd
have
to
copy
paste
that
that
little
subsection,
where
we
say
okay
now,
I
want
to
set
these
default
approval
rules.
But
I
only
want.
B
Merge
request
settings
point
to
this
custom,
ci
path,
prevent
project
maintainers
from
changing
any
settings,
or
you
know
something
like
that.
So,
instead
of
having
to
copy
paste
this
framework
selection
everywhere,
we
have
them
define
those
common
theme
settings
in
this
one
place
and
then
every
project
they
apply
that
label
to
would
then
apply
those
controls
and
say:
okay,
maintainers,
don't
have
their
normal
permissions.
The
ci
pipeline
is
going
to
be
or
the
the
pilot
is
going
to
be
comprised
of
both
this
local
and
external
configuration
file.
B
A
A
B
Automatically
inherit
down,
but
subgroups
and
projects
should
be
able
to
change
those
settings,
and
I
think
that's
like,
I
think,
that's
a
good
path
because
then
later
we
can
figure
out
like
okay.
How
do
we
lock
these
down
for
compliance
or
regulated
projects?
And
to
me
that
seems
to
be
in
line
with
our
values
of
it's,
not
disruptive.
B
It
is
convenient
because
they
can
apply
a
standard,
but
then
local
group
owners
and
project
maintainers
can
change
it
to
their
needs.
But
then
later
we
can
introduce
the
very
selectively,
disruptive
enforcements
that
allow
the
owners
or
admins
to
enforce
things
for
this
small
handful
of
projects
that
they
want
to
regulate.
A
A
A
It's
it's
it's
a
container
of
a
way
you
can
group
settings
and
if
I
can
think
of
it's,
I
think
I've
posted
up
here,
but
I'm
keen
to
hear
your
thoughts
in
so
have
project
and
then
group
an
instance.
If
you
don't
have
compliance
in
that
space,
you
have
projects
inherit
from
groups
inherit
from
from
instance.
A
Now
compliance
introduces
an
interesting
dynamics
here,
so
we
have
so
kind
of
think
you
may
be
in
you
know,
compliance
somewhere
in
between
groups
and
instance,
where
you
can
say
you
know,
project
inherits
from
group
and
inherits
from
compliance
if
you
have
instance
that
might
be
high
up.
So
that's
compliance
inherit
from
instance,
but
maybe
not
the
right
move
there.
A
B
A
B
And
then
the
second
problem
would
then
be
okay,
now
that
I
can
like
automate
and
standardize
this
project
template
essentially
or
the
settings
template
now.
I
want
to
have
that
apply
on
new
projects
or
inherit
down,
and
I
don't
want
maintainers
in
this
project
over
here
to
be
able
to
change
that,
and
I
think
that's
where
the
compliance
labels
could
come
in.
B
Gotcha
and
I
could
almost
kind
of
see
just
like
a-
I-
don't
know:
random
random
thought
yeah.
Maybe
it's
in
the
compliance
dashboard,
but
like
a
control
panel,
where
you
s
where
you
specify
that,
like
any
project
with
a
compliance
label,
should
have
this
default
profile,
and
maybe
that's
maintainers
can
do
x,
y
and
z
things,
but
they
can't
change
any
of
the
project
settings
and
they
can't
change
or
do
certain
actions
that
maintainers
normally
could
do
any
label
or
any
project
with
a
compliance
label.
A
A
Yeah
sure
it's
an
interesting
problem
to
solve,
isn't
that
to
to
put
out
a
curveball
here
for
my
request
of
provost
the
way
that
its
structure
is
different
from
push
roles,
so
it
you
can't
simply
like
from
the
technical
standpoint
to
slide
it
the
same
way
as
push
holes,
which
I
think
it's
was
not
right
like
it
should
be
kind
of
structured
in
a
similar
way.
So
that's
what
we
don't
have
to
kind
of
repeat
the
same
effort
to
elaborate
on
that.
A
So
that's
the
extra
effort
to
kind
of
arrogate
these
rules
at
the
time
where
the
projects
or
at
the
mri
level
approval
settings
apply.
We
have
to
aggregate
or
jump
between
different
tables
to
get
to
the
to
the
to
the
end
result
where
push
rolls
actually
done
inside
one
table.
So
it's
more
performant.
A
B
Yeah
well,
and
I
think
too,
one
of
the
lessons
learned
between
the
instance
level,
mr
rules,
that
you
built
and
the
group
level
push
rules
and
just
group
level.
Anything
is,
I
think
we
should
probably
start
a
focusing
first
on
group
level,
one
because
it
caters
to
both
com,
customers
and
self-managed.
B
Only
going
to
be
the
minority
of
customers,
which
we
could
then
do
small,
quick
iterations,
eventually
at
the
instance
level,
to
give
them
that
level
of
control,
and
I
don't
think
we
would
have
learned
that
if
we
hadn't
have
done
what
we've
done
so
far.
But
I
think
where
I
see
the
incense
level
merge
request
approval
rules
going
potentially.
Is
we
treat
that
area
of
the
admin
panel?
B
As
sort
of
this,
I
don't
know,
maybe,
like
jeremy,
raised
a
great
issue
around
doing
like
a
compliance
check,
and
so
maybe
we
take
those
check
boxes
and
we
add
on
to
it,
and
maybe
we
do
like
a
library
of
common
settings-
and
we
say,
like
hey,
like
check
all
the
settings
that
you
want
to
ensure
enabled
across
your
instance,
and
we
then
use
that
as
some
frame
of
reference
to
measure
against
and
say.
Okay,
you've
told
us
that
these
32
settings
should
be
enabled
or
have
these
values.
And
now
we're
going
to
go.
B
Look
at
all
of
the
projects
in
your
group
or
all
the
regulated
projects
in
your
your
group
or
namespace
to
let
you
know
which
ones
are
compliant
or
which
ones
have
violations
and
stuff
like
that.
So
I
think
there's
still
a
cool
opportunity
in
that
regard.
Yeah
yeah,
but
then
that's
again,
that's
one
of
those
we're
like.
B
Maybe
we
have
to
bring
it
to
doc
to
group
at
some
point
for
com,
and
it
goes
back
to
your
point
from
earlier
in
this
call
where
we
say
you
know
it
needs
some
place
between
group
and
instance
level,
and
I
think
melissa
in
the
access
group
is
working
on
a
workspaces
construct.
I
think
yeah
we're
working
with
workspaces,
but
yeah
yeah
a
lot
of
really
tough
problems
to
solve.
A
Yeah,
but
seeing
if
we
we
would
treat
those
at
least
even
just
at
the
data
store
level
having
these
in
one
place-
and
you
know
just
distort
you
know-
might
request
approval
settings.
So
these
are
the
settings
that
apply
for
compliance,
ay,
z
and
then
this
is
the
compliance
apply
for
group
and
then
we
can
figure
out.
You
know
what
thing
how
it's
kind
of
how
the
rules
are.
A
You
know
at
the
later
points,
at
least
we're
recording
this
in
the
same
place,
the
same
for
push
rules.
That's
what
happened.
I
think
we
had
it
all
kind
of
in
the
same
tables
and
there,
if
you
happen
to
change
the
way
the
rules
apply
like
whether
that's
group
come
first
or
compliance
comes
first,
it's
really
easy.
You
feel
like
less
moving
parts
where
you
know
most
request
approvals.
I
think
it's
digitally.
We
have
it
in
two
different
places.
B
A
A
B
Yeah,
I
can
maybe
schedule
a
call
with
if
it's
ecosystem
that'd
be
patrick
dooley
and
just
pick
his
brain
on
it
a
bit
because
I'd
like
to
spend
some
some
cycles
on
it
with
you
and
dan
or
whomever,
and
to
think
about
what
it
is
you're
talking
about,
because
there's
another
issue
I
created
around.
Creating
this
risk
library,
where
the
initial
thought
is
customers
could
define.
Let's
say,
there's
a
line
item
and
says:
merge
requests
opened
that
have
only
one
minimum
required
approval
is
a
risk
score.
B
That's
probably
not
the
right
way
to
to
define
those,
but
something
like
that
where
we
create
this
library
that
we
can
then
say:
okay,
once
we've
defined
what
risk
looks
like
within
gitlab,
then
when
we
create
an
issue
when
we
open
an
mr,
when
we
merge
that,
mr,
when
we
take
certain
actions,
we
can
assign
risk
ranks
or
just
weights
to
it,
and
I
think
that's
going
to
require
some
underlying
consideration
around.
What
does
that
schema
look
like,
and
how
do
we
deal
with
those
relationships
and
then,
similarly,
we
eventually
want
to
build
out.
B
You
know
a
mapping
between
things
like
all
of
the
controls
in
the
pci
dss
and
settings
and
configurations
in
gitlab,
so
I
think
we're
doing
a
lot
of
work.
That's
gonna
involve
these
relational
or
relationship
type
of
considerations,
and
it's
probably
good
for
us
to
start
now,
even
just
kind
of
like
slowly
and
chipping
away
what
we
think
this
could
manifest
as
whether
it's
one
or
n
number
of
these
different
models.