►
From YouTube: Discussion: Templated workflows for GitLab CI/CD
Description
We're trying to determine the best way to help customers implement compliance checks into their GitLab workflows. It's a challenging problem, but we're making progress with each conversation.
A
Yeah
so
so
I
agree.
It
would
be
good
to
align
on
specific
language
because
for
me
like
using
the
the
terminology
of
like
a
required
pipeline
and
maybe
that's
the
benefit
of
moving
toward
like
prescriptive
pipeline
or
even
prescriptive
workflow
is
it
in
theory
doesn't
mean
that
very
specific
thing,
because
ultimately,
what
we're
trying
to
solve
for
is
you
know,
organizations
have
a
requirement.
Okay.
Let
me
back
up
a
little
bit.
A
But
they
helped
confirm
was
that
when,
when
an
organization
says
we
need
to
have
these
jobs
or
these
tasks
that
are
carried
out
within
our
CI
CD
workflow
it's
because
their
organizational
policies
define
that
it
has
nothing
to
do
with
the
auditor
cuz.
The
auditor
doesn't
come
in
and
say,
hey,
look
like
here's.
Here's
the
checklist,
they're
just
gonna,
say
here's
the
framework
that
you're
trying
to
certify
against.
A
Let
me
see
the
policies
that
describe
what
you
say
you're
doing
now,
let's
audit,
what
you
say,
you're
doing
and
so
talking
the
auditors
is
valuable
in
some
ways,
but
largely
this
is
a
conversation.
I
believe
that
we're
it
seems
like
we're
trying
to
debate
with
customers
who
know
their
workflows
really
well,
and
they
know
the
process
and
the
reason
those
process
exists
right,
like
managing
risk
managing
consequence
at
the
end
of
it.
A
So
if
they're
telling
us,
like,
my
policy,
dictates
a
B
and
C
and
I
need
to
make
sure
that
that's
implemented
within
gitlab
I
understand
why
we
don't
want
to
implement
it
in
the
previous
proposal,
because
it's
very
disruptive,
but
we
do
have
to
solve,
for
it
and
and
I'm
fairly
convinced
at
this
particular
point
in
time.
It
is
a
matter
of
pipelines,
I
think
in
the
future.
As
we
start
developing
like
best-in-class
products
such
as
scanners,
like
one
one
customers,
feedback
was
the
reason
we
don't
use
at
least
get
labs
scanning
capabilities.
Natively.
A
Is
that
it's
not
what
we
consider
to
be
best
in
class,
and
so
it's
not
worth
the
migration
time
and
cost
to
migrate,
thousands
of
developers
to
a
brand
new
product
or
functionality,
because
that's
very
costly
for
them.
So
in
the
interim,
which
is
probably
you
know
in
number
of
months
or
years,
we
have
to
have
some
sort
of
solution,
and
maybe
we
don't
like
that
solution,
but
it
might
be
what
they
actually
need.
B
A
So
the
one
customer
I
spoke
with
that
I've
referred
to
in
the
issue,
I'm
still
waiting
for
them
to
send
me
over
like
that
itemized
list,
but
they
did
a
non
recorded
screen
share
because
they
had
to
get
approval
from
legal
to
share
it,
but
they
basically
pulled
up
I,
think
it's
Atlassian's
bamboo
product
and
it's
it
panel-
looks
like
a
user
friendly
UI
version
of
a
Yambol
file.
They
had
this
left
sidebar
that
showed
the
different
stages
and
jobs
within
the
pipeline.
It's
like
they
had
a
building
test
stage,
showing.
B
A
So
so
they
had
this
set
of
stages.
Each
stage
with
you
know
the
respective
jobs,
the
build
and
test
stage
had
a
memory
serves
only
five
or
six
jobs
and
in
their
particular
case,
what
they
want
to
do
is
they
say
we
just
want
to
have
this
set
of
stages
in
gitlab,
and
we
want
to
make
sure
that
all
that
developers
have
two
options.
They
can
use
this
set
of
stages
and
if
they
use
that,
then
they
can
add
stuff
to
it.
And
we
don't.
A
We
don't
really
care
what
they
add
to
it,
because
this,
like
core
set
of
stages,
is
what
we
want
to
enforce
an
action
on.
If
they
don't
want
to
use
that,
then
we
will
let
them
create
their
own
set
of
stages,
but
they
have
to
come
to
us
internally
at
our
customer
org
to
then
seek
approval
to
use
that
in
their
project.
A
B
Helpful
so
when
I'm
talking
to
customers
about
how
their
Jenkins
is
configured,
which
is
another
tool
to
set
up
series
of
steps,
that
of
code
is
going
to
go
through,
they
have
a
very
different
way
to
permission:
access
to
change
each
stage
inside
of
a
Jenkins
configuration.
So,
for
example,
developers
can
you
can
give
them
permission
to
only
edit
the
build
stuff.
The
test
stuff,
the
environment
line,
like
each
line
in
your
llamo
file,
has
its
own
ability
of
permissions
in
the
deccan
sub.
B
A
I
think
I
understand
that,
yes
and
and
that's
terminology
that
they
used
that's
terminology
that
resonated
with
them,
and
the
idea
would
be
that
this
set
of
steps
is
defined
in
some
fairly
global
way.
That
developers
could
then
consume.
Now.
One
important
caveat
there
is
that
this
particular
customer
wants
it
to
be
an
optional
consumable
thing.
They
call
it
the
paved
road,
but
they
want
to
be
optionally,
consumable
and
there's
that
backup
approval
process
if
they
deviate
from
that
paved
road.
A
B
It
so
it
sounds
like
what
system
this
doesn't
differ
from
a
template
inside
of
get
lock.
It's
like
when
we
look
at
the
other
DevOps
template.
It's
an
option
that
you
can
pull
from
your
repository
and
set
from
a
drop-down
menu.
So
here
I
think
that
the
problem
that
we're
trying
to
solve
is
allowing
users
to
add
custom
project
templates
and
have
those
be
the
only
template
options
inside
of
the
drop-down
menu.
But
it
also
means
that
the
developers
can't
go
back
and
edit
that
template.
They
can
only
extend
it
right.
B
A
A
B
A
That's
home
my
mind
is:
is
visualizing
this
and
when,
when
I
described
or
like
engage
with
the
customer
about
like
parent-child
pipeline
like
yeah,
it
sounds
like
what
we
need
in
that
context
was
the
parent
pipeline.
Is
this
thing
that
you
define
and
the
child
pipeline
is
what
runs
locally
in
the
project?
I?
Don't
think?
That's
necessarily
the
path
forward,
because.
B
The
parent,
the
parent
pipeline
in
this
case,
has
to
exist
in
the
same
project,
so
it
would
be
like
a
configuration
custom
path
that
then
locks
down
a
core
file
and
then
the
local
project
can
then
edit.
It
so
I
think
part
of
the
challenge
that
I'm
having
right
now
is
that
we're
trying
to
like
address
a
really
broad
set
of
use
cases
with
this
problem
and
I'm
wondering
if
there's
ways
to
segment
the
use
case
and
define
like
the
five
job
to
be
done.
Five
session
arbitrary
number.
B
But
we
had
full
of
jobs
to
be
done
that
we're
trying
to
accomplish
with
what
your
your
prescriptive
pipeline
is.
It's
called
because
what
I'm
hearing
is
seemingly
something
that
we
already
do
and
get
lob
today,
which
is
allowing
users
to
specify
custom
project
templates
and
if
they
can
specify
custom
project
templates,
they
can
do
anything
around
allowing
failures.
They
can
say
that
these
steps
will
fail
your
job.
They
can
say
that
your
merge
won't
happen
because
what
happened
to
master
it
has
I'm
a
deployment
production.
B
It's
all
about
controlling
each
stage
of
your
of
your
code,
going
through
acceptance.
So
I'm
interested
to
hear
if
this
is
just
about
building
out
sample
projects
and
templates
and
having
customers
like
see
those
or
like
proliferating
like
marketing
about
those
different
project
templates
rather
than
like
building
something
new,
because
I
don't
think
we
need
to
build
anything
new.
We
have
the
project
templates
already
there
ya.
A
Know
I
think
that's
a
valid
point.
I
think
that
would
work
for
a
brand
new
customer
and
setting
up
their
environment
for
the
first
time,
I'm,
not
sure
that
it
applies
to
the
customers,
who
already
have
like
hundreds
or
thousands
of
projects,
at
least
not
without
a
lot
of
effort
to
maybe
go
implement
that
change.
Well,.
B
A
A
Yeah
and
I
think
that's
what
they
want
is
a
universal
right
like,
so
that's
a
so
why
I
kind
of
brainstorm
around
this
idea
of
something
we
define
at
the
group
level
is
because
that's
what
customers
have
asked
for,
at
least
in
kind
of
the
forced
includes
concept
to
me
as
kind
of
like
a
relatively
fresh
set
of
eyes.
It
makes
sense
and
I'm
not
saying
it's
right
but
like
to
me.
A
It
makes
sense
that
why
why
couldn't
we
have
this
group
level
experience
where
I
can
say
here
the
the
jobs
that
I
would
like
to
have
run
for
all
of
these
like
specific
projects
and
then
kind
of
like
tailor
it
from
there
I'm
sure.
That's
not
feasible,
I'm
sure,
there's
issues
with
that
or
challenges,
but
like
yeah.
B
I
would
say
that
we
should
probably
evaluate
a
group
template
like
a
group.
The
amyl
file
template
really
like
the
way
that
get
lab
works
today
is
that
GMO
files
are
very
specific
to
each
repository
in
each
repository
is
project
level.
So
we
would
be
changing
the
paradigm
of
project
based
resources
to
groups
based
resources
that
actually
render
projects
based
actions.
So
I
think
it's
possible
I'm
doing
that
on
the
really
expanding
the
side.
B
Where
we're
saying
hey,
we
want
to
be
able
to
manage
releases
at
the
group
level,
but
really
what
we're
doing
is
providing
convenient
paths
to
help
users
dig
into
the
project
from
a
group
view,
so
we're
creating
that
visibility
at
the
group
level,
but
actioning
at
the
project
level
for
the
animal
files.
My
fear
that
we're
having
here
is
that
we're
gonna
implement
it.
B
At
the
group
level,
people
aren't
going
to
use
them
because
they
don't
have
granular
enough
of
controls
at
the
project
level
so
like,
and
then
we're
gonna
have
to
elevate
a
bunch
of
level
permissions
or
create
a
whole
new
permission
structure
to
support
people
at
the
group
level,
so
that
they're
not
able
to
do
things
at
the
project
level,
because
we
just
don't
have
that.
That's
all
the
way
guilt,
Labatt's,
that's
what
the
paradigm
the
killer
has
today.
I,
don't
know
if
it's
worth.
B
If
it's
actually
solving
the
problem
either
is
it
does
sound
like
when
I
was
talking
to
another
financial
services
customer
they
just
really
wanted
to
not
rewrite
their
Jenkins
configurations
that
I
give
up,
so
the
cost
is
having
to
rewrite
and
tool
get
lab
to
match
their
current
implementation
has
a
really
high
switching
cost
for
them.
So
we
just
have
this
barrier
of
wanting
to
just
use
things
out
of
the
box
exactly
how
they
currently
have
a
configure.
B
I
feel
like
that's,
probably
what
we're
gonna
run
into
with
all
these
mature
and
a
price
customers
anyways,
but
I
would
say
prescriptive
pipeline
required
pipeline.
All
those
are
templates,
I
think
those
are
just
templates
and
gitlab
and
the
next
that
the
required
and
prescriptive
part
is
permissioning.
And
how
do
we
permission
access
to
those?
It's
really
like
we're
just
saying
that
you
have
this
template
and
we
don't
want
people
to
edit
the
template.
A
So
I
think.
Okay,
so
let
me
let
me
write
this
down
so
I.
Leave
that
yeah
Alex
you're
absolutely
correct.
That
I
think
a
quick
win
at
least
for
one
customer
probably
for
multiple
is
a
lot
like
creating
the
capability
where
a
project
template
can
be
front
are
preloaded
with
a
pipeline
definitions
like
a
configure,
yeah
Mel
configuration
file
right.
Is
that
the
gist
of
it
yeah.
B
B
And
this
is
where
enforcement
of
the
the
stages
at
the
merge
request
level
it
just
you
can
build
out
linters,
you
can
build
out
requirements
that
fail
your
job,
it's
kind
of
like
when
we're
doing
our
release
post
stuff
and
if
we
have
an
extra
space,
there's
a
linter
that
runs
and
fails
our
jobs.
You
know
so
like
those
are
the
kinds
of
things
that
we
can
help.
Customers
define
and
work
out
so
that
their
jobs
fail.
If
they
don't
meet
these
certain
style
criteria
and
at
the
merger
quest
level.
B
It's
such
a
you
know
a
small
change,
but
again
like
we're
thinking
about
what's
the
downstream
impacts
to
developers
producing
code
and
value
for
their
customers,
so
we
do
have
to
balance
like
how
much
do
we
want?
How
much
power
do
we
want
to
give
people
to
block
merge,
request
progression
through
stages?
And
that's
that's
this
whole
idea
of
we
don't
want
to
require
people
and
slow
down
the
process
of
deployment,
but
we
do
enforce
this
concept
of
managing
the
steps
and
approval
through
the
merge,
merge
request
train.
B
A
That
is
my
understanding,
I'm
also
pretty
comfortable
with
not
so
like
I'm
pretty
comfortable
with
making
things,
at
least
in
the
CI
part
fairly
like
smooth
and
passive
right,
because
that
murder
quest
approval
is
the
final
human
interaction
to
say
there
is
or
is
not
a
problem
with
everything.
That's
happened
at
this
point.
I'm
gonna
make
a
decision
to
approve
it
or
not.
B
Typically,
what
customers
are
doing
they
deploy
to
multiple
stages
or
environments,
so
they'll
deploy
to
a
QA
environment
and
once
they
get
the
final
stamp
of
QA,
it's
gonna
promote
to
a
production
environment
and
typically,
there's
like
a
clean
up
that
job.
That
happens
after
that
to
like
scrub,
the
existing
environments
redeploy
new
clusters,
whatever
whatever
they
want
to
do,
whatever
their
setup
is,
but
it
doesn't
really
mean
that
they're
going
to
scan
production
again
and
revert
that
change.
That's
not
really
how
people
do
things
they.
B
A
B
Seeing
I'm
revisiting
your
diagram
and
mural
I,
remember
you
walking
me
through
that.
So
pre
build
is
going
to
be
everything.
That's
about
creating
the
image
and
package
the
developer
is
going
to
make
their
full
request.
They're
gonna,
pull
that
image
out
from
the
system
and
then
they're
going
to
make
their
changes.
This
is
in
the
merge
request,
they're
going
to
promote
changes,
they're
going
to
merge
those
changes
into
their
master
branch
once
that
master
branch
is
complete,
they're
gonna
shift
that
to
code
review.
B
So
this
is
all
in
that
host
pre-build
stage
that
we're
in
the
build
stage
they're
going
to
that
approver
is
gonna
stamp
it
it's
gonna,
get
merged
into
the
master
branch
that
change
will
get
merged
with
master
branch,
that
master
branch
is
gonna,
get
deployed
to
a
QA
environment
to
get
tested
and
stamped.
So
now
we're
leaving
the
build
phase
because
it's
been
repackaged
into
another
image
for
for
a
production,
employment,
and
now
it's
going
to
the
test
stage.
The
test
stage
is
going
to
approve
it
and
they're
gonna.
A
A
B
B
B
A
A
A
That
would
explain
why
his
schedule
is
especially
this
because
yeah,
the
at
the
end
of
the
day,
I
think
what
we've
talked
about
here
as
far
as
like
yeah,
like
here's,
a
project
template
I,
think
that
solves
the
at
least
part
of
from
now
forward.
Here's
how
you
can
let
your
developers
consume
this
configuration
right.
B
B
It
still
will
be
like
it'll
still
have
its
own
project,
so
this
is
where,
like,
if
you
don't
have
a
dedicated
ops,
team
or
you're
running,
get
off
steams,
where
it's
all
integrated
customers
are
gonna
push
back
a
little
bit
because
they're
like
we,
don't
have
the
resources
to
not
only
maintain
our
application
code
and
our
infrastructure.
But
now
these
extra
templates
that
you're
making
us
uphold
one
in
another
tool,
I
can
say
developers
I,
don't
want
you
at
it
line,
442
right.
A
B
A
A
conversation
has
occurred
already,
but
it
feels
like
if
we
had
an
experience
where
and
bear
with
me,
but
like
you,
let
seeing
group
settings,
you
have
a
page
called
pipeline
configuration
just
rough
idea
and
there
you
literally
just
paste
your
yeah
Mel
configuration.
Let's
say
this
is
the
template
that
they
want
to
use
you
in
theory.
We
can
maybe
in
theory
maybe
we
could
have
logic
there
or
split
it
up
into
separate
like
input
fields
to
say
like
for
this
stage.
For
that
like
how
you
know
how
you
can
like
add
rules
right.
A
So
you
add
a
room.
So
this
row
is
my
verify
stage
and
I
have
maybe
three
items
in
there
that
are
like
the
locations
of
the
scripts
or
runners,
I,
guess
or
the
jobs
owner
run,
and
so,
if
we
break
it
out
like
that,
then
we
could
feasibly
say
this
UI
element,
maybe
he's
only
visible
to
group
owners,
but
I
get
the
project
level
or
I
don't
know.
B
A
B
It's
it
will
be
a
challenge
for
us
to
understand
like
when
we
implement
something
in
the
front
end.
How
is
that
going
to
interact
with
the
animal
file
and
will
it
be
able
to
pool
those
different
lines
and
then
for
animal
cells
that
are
particularly
large
or
EML
files
that
then
reference
another
project
so
that
seek
the
custom
CI
configuration
path?
Example
it'll.
B
A
B
Whole
whole
front
end.
There
is
really
the
configuration
file
that
we
have
the
whole
Jenkins
tool.
The
way
you
write
it
out,
the
way
that
you
specify
it
like
it
gives
you
the
options
to
like
protect,
highlight
you
can
identify
what
chunks
of
successive
code
you
want
to
the
permission
differently.
It
just
doesn't
it's
just
not
the
same
as
having
the
super
flexible,
easy
to
use
the
mo
file,
but
it
does
give
opening
is
the
ability
to
granularly
control
the
configuration
so.
B
A
Okay,
yeah
I
feel
like
if
there
is
just
a
way
to
make
those
passive
to
where
they
weren't
a
contingency
like
they
do
run.
But
then
at
the
merger
quest
you
see
that
oh,
these
forced
includes
ran,
but
one
of
them
failed.
Then
the
human
is
making
the
decision
to
block
that
progress,
but
it's
not
necessarily
failing
the
whole
pipeline
or
like
not
preventing
the
rest
of
the
pipeline
from
starting
and
succeeding,
and
it's
not
necessarily
impacting
negatively
the
whole
pipeline.
It's,
but
it
is
still
there.
B
Yeah
and
I
think
that
it
it
could
slow
down
things
really
really
bad.
When
we
look
at
build
times
say
that
you
say
that
you're
submitting
a
commit
to
change
a
typo
is
a
front
of
it
front.
End
of
an
application.
Now
that
force
includes
is
going
to
take
those
three
character,
changes
and
run
potentially
minutes
and
minutes
minutes
minutes
of
scans
for
your
15,000
line.
Codebase
right!
Oh!
That's!
B
A
B
That
could
be
like
a
really
immature
way
of
like
abstracting,
that
application
and
forced
includes
could
see.
Lots
of
benefits
for
horse
includes,
like
let's
say
that
they
only
have
it
on
tags,
so
you're
only
running
forced
includes
on
releases
production
or
it's
only
on
the
master
branch.
When
you
use
those
rules,
then
the
forced
includes
have
become
much
more
meaningful
because
it's
restricted
to
just
branches
that
are
about
merging
to
a
change
for
a
customer.
B
A
Learning
what
I've
learned
I
feel
like
that's,
maybe
not
entirely
necessary,
so
I
just
like
to
kind
of
do
that
mental
exercise.
But
like
is
there
a
way
that
we
could
just
implement
hard-coded
blocks
that
say:
oh
you
can
only
you
know,
designate
force
includes
for
like
master
branch
or
certain
things.
B
Well,
let's
think
about
in
CD
applications
when
there
isn't
a
manual
check
on
that
when
there
isn't
somebody,
that's
like
clicking
a
button
to
do
deployment
and
it's
running
all
of
their
jobs
get
deployed
to
production
people
push
at
will.
A
forced
includes,
will
slow
people
down
because
it'll
be
scanning
you'll,
have
hundreds
of
thousands
of
pipelines
running
for
all
the
changes
of
these
thousands
of
developers
every
day
and
each
of
those
pipelines
are
going
to
run
those
scans
because
you're
deploying
each
individual
changed
your
production
environment.
A
And
that's
curb
if
I'm
wrong,
but
that's
that's
in
the
current
paradigm
that
they
are
this
like
disruptive
required
thing
right,
but
if
they
were
somehow
passive
and
the
person
making
the
decision
to
approve
that.
Mr
could
see.
Oh
it's
still
running,
but
you
know
what
this
is
a
three
character
change.
I!
Don't
need
to
wait
for
that.
I
was
gonna,
go
ahead
and
approve
this
yeah.
B
So
when
you
make
things
passive,
they
lose
their
usefulness
and
people
will
likely
not
adopt
those
features
because
they're
like
okay.
Well,
why
am
I
even
caring
about
this?
If
it's
not
changing
my
workflow
right
so,
and
maybe
that's
like
me,
misinterpreting
what
we're
meeting
with
passive
so
I
could
see
us
collecting
this
information
with
every
merge
request
and
surfacing
a
report
to
a
customer
being
like
hey,
you
actually
deployed
for
vulnerabilities
to
production.
B
Here's
here,
they're
right
here
here,
they're
at
without
blocking
people's
deployments
to
production,
surfacing
those
things
after
the
fact
or
sending
like
a
notification
or
a
report
after
each
deployment
to
master
from
master
to
production.
That
says,
here's
all
the
things
that
we
found
you
may
want
to
fix
them,
but
again
like
passiveness.
It
alludes
to
it
being
not
actionable
right.
It's
just
hatched
happening.
B
A
B
A
We
should
still
be
saying
that,
even
though
you
said
no
go
ahead
and
merge
this
anyway,
because
you
don't
want
to
wait
on
all
those
tests
or
jobs
for
this,
like
really
minor
change,
we
should
still
in
the
merger
quest
or
in
some
other
reporting
mechanism,
show
it
like
yeah.
These
eventually
finish.
Ten
years
later,
here's
like
the
output
for
that
and
that
should
still
be
available.
A
B
B
A
A
B
Allow
failing
retry
after
X
like
they
can
use
all
other
commands
within
that
forced
includes
job
like
it's
irrelevant,
it's
so
flexible
that
customers
can
have
that,
but
still
allow
failure.
So,
when
I
here
forced
includes
like
what
were,
what
we're
trying
to
remove
is
the
power
to
mandate
that
a
developer
go
through,
something
that
doesn't
necessarily
benefit
the
end-user
right.
So
someone
can
it
can
build
out
their
Yama
file
and
do
all
the
things
that
you're
saying,
but
this
could
be
us
being
prescriptive
with
it
like
if
you're
gonna
use
force
includes.
B
B
A
This
so
difficult
right
is
because
cut
at
the
end
of
the
day.
Customers
want
to
block
bad
changes
to
production
and,
at
the
end
of
the
day,
get
lab
doesn't
want
to
put
customers
in
a
position
where
they've
created
this
workflow
within
get
lab
that
they
are
now
bankrupt
because
they
couldn't
get
something
into
production
because
of
all
of
the
forced
includes
or
require
jobs
or
whatever
it
is
that
cluttered
up
the
pipeline.
It
also
seems
like
this
is
something
that
customers
want
to
run
on
very
specific
workflows.
A
So,
like
it's,
not
an
all
projects,
thing,
it's
a
regulated
projects,
thing
and
I
think
that's
an
important
distinction
as
well,
not
not
that
that
lessens
the
impact
or
the
potential
consequence
that
Sid
is
concerned
with,
but
it
does
I
think
reduced
the
scope
right
like
we're
not
talking
about
allowing
customers
to
apply
this
to
all
15,000
projects,
only
maybe
like
10
to
50,
depending
on
what
their
environment
looks
like
yeah,
I,
just
I'm,
still
just
kind
of
at
a
loss
on
what
the
solution
maybe
looks
like,
but
this
conversation
has
been
really
helpful.
Yeah.
B
I
think
part
of
this
is
understanding
how
people
want
to
manage
configuration
for
yellow
files
and
I.
Think
that,
like
that's
a
greater
problem
that
we
have
to
solve,
we
need
to
empower
a
single
individual
developer,
who's
contributing
with
gitlab
to
their
product,
and
we
need
to
empower
enterprises
to
be
able
to
control
those
contributions.
So
those
two
things
are
inherently
at
odds
with
each
other,
because
speed
and
compliance
aren't
always
going
to
be
seeing
eye
to
eye.
B
This
could
be
accomplished
with
parent/child
pipelines
like
you've
mentioned
before
this
can
be
accomplished
by
a
CI
custom
configuration
path.
This
can
be
accomplished
by
building
out
a
new
paradigm
for
managing
permissions
by
jobs
inside
of
gitlab,
but
I
think
that
that's
the
bigger
compliance,
scope
and
problem
that
we
need
to
solve
I,
don't
think
pipelines,
I
think
we're
being
too
myopic
when
we
want
to
manage
pipelines.
I
think
we
need
to
think
about
like
bigger
implications
of
how
people
are
using
yeah.
A
No
I
think
you're
so
you're
like
the
third
or
fourth
person
who
said
that
yeah
they
want
to
basically
bring
Jenkins
in
to
get
lab,
which
I
think
is
an
important
insight.
I
know
that
the
access
group
is
working
on
I,
believe
more
granular
permissions
in
the
pipeline.
I,
don't
know
what
the
plans
are
there.
So
I'll
circle
back
with
Jeremy
and
Melissa.
A
Yeah
I
mean
your
point
is
valid,
that
we
need
to
understand
a
more
abstracted
view
of
how
they're
wanting
to
work
within
get
lab
I
feel
at
least
a
handful
of
customers
have
provided
exactly
that
insight
and
that's
largely
what's
kind
of
like
driving
this
conversation.
From
my
perspective,
which
I'm
sure
maybe
sounds
repetitive
to
anyone
who
might
watch
this
video
of
like
no
Matt,
we
told
you
like
no
forced
includes
like
I
know,
but
this
is
being
told,
but.
B
And
like
really
look
at
what's
there,
what's
our
problem
there,
it's
off
I,
think
you
took
a
really
good
approach
by
talking
to
the
auditor
people
in
our
in
our
group
because
really
like
now,
this
is
a
change
management
thing
of
hey.
Do
we
concede
to
customers
and
rebuild
some
functionality,
that's
available
in
Jenkins
and
to
get
labs,
or
do
we
decide
that
we
really
don't
want
to
support
these
workflows?
Because
we
can
choose
that?
B
A
And
and
I'm
really
glad
you
say
that,
because
I've
at
least
right
now,
my
opinion
can
and
probably
will
change.
It
really
feels
like
okay,
if
we
don't
like
what
they're
telling
us
and
what
the
solution
seems
to
need
to
look
like
and
granted
like
I
still
need
to
do
some
more
validation
and
research,
but
right
now,
at
this
point
in
time,
it
feels
like,
let's
just
commit
that
we're
not
going
to
build
this,
because
we
can
tell
customers
look
you're,
just
gonna
have
to
build
that
custom
tooling.
A
If
that's
how
you
want
it,
then
you
need
to
build
that
and
we
can
maybe
enable
that
with,
like
maybe
system
hooks
of
some
sort
or
like
event
hooks
and
maybe
API
endpoints
or
whatever.
They
need
and
then
provide
them.
Some
guidance
on
how
to
build
those
types
of
things
via
professional
services
or
solution.
A
Architects,
whatever,
but
you
know,
send
me
in
a
comment
that
I
agree
with
which
is
like
look
if
they're
trying
to
shove
certain
things
into
their
pipelines
like
let's
take
out
what
we
can
and
build
native
features
in
Gaelic
I
agree
with
that.
But
the
problem
is:
is
one
we're
still
doing
discovery
on
what
exactly
those
are?
The
two
the
little
info
we
do
have
suggests
that
it's
all
very
proprietary
custom
stuff
that
we're
now
kind
of
back
in
the
same
point
of
like.
Are
we
gonna
build
this
highly
customized
feature
for
one
particular
customer?
A
Maybe
that's,
okay,
but
I
do
think
there
are
opportunities
in
terms
of
like
evidence
generation,
as
you
well
know,
reporting,
which
is
something
that
I
can
help
with
on
an
order
of
reports
category.
So
there
are
elements
we
can
pull
out
of
the
pipeline,
but
there's
a
lot
of
stuff.
We
can't
that
I'm,
aware
of
and.
B
I
think
that
that's
where
we
can,
the
position
we
can
stand
here
is
as
a
single
platform.
We're
gonna,
make
your
job
visible
and
as
transparent
as
possible,
but
we're
not
going
to
build
out
your
blocks
and
since
get
lab
is
so
extendable.
You
should
be
able
to
layer
the
tooling
that
you
want
on
top
of
it,
but
I
do
feel
like
we
have.
B
We
have
the
framework
in
place
that
if
we
were
to
get
the
right
si
the
right
sort
of
commercial
services,
people
to
help
build
these
like
build
these
projects,
and
these
use
cases
with
us,
then
I
think
we
can
find
a
solution
that
will
work.
For
you
know
50
percent
of
the
regulated
use
cases,
but
as
we
start
to
uncover
these
super
old
enterprise
companies
like
we're
gonna
hit
all
their
crafts
and
all
of
their
own
organizational.