►
From YouTube: 09292023 GitLab Multi Approval Development
Description
Demonstration of how a team in a regulated environment could set up and operate a fully automated development process in GitLab using Merge Request Approvals and Pipeline Approvals.
A
My
name
is
Samir.
Kamani
I
will
be
presenting
today
a
prototype
project
that
is
supposed
to
address
a
couple
of
cicd
pipeline
approval,
questions
that
were
posed
by
a
customer
recently.
So
the
context
is
that
there
is
a
project
and
it
goes
through
a
merge
request
process
where
only
certain
jobs
are
supposed
to
run
the
the
outcome
of
those
jobs,
May
influence
the
approval
of
that
merge
request.
Then.
A
Subsequently,
once
the
merge
request
is
merged,
then
the
pipeline
would
actually
have
other
kinds
of
jobs
that
would
run,
of
which
one
of
them
would
be
a
deployment
job
into
the
production,
environment
or
production
like
environment,
where
the
there
would
be
another
approval
for
a
person
to
approve
and
deploy
into
that
environment.
So
I
will
present
to
you
now
how
that
would
operate
within
gab
here's
our
project.
The
project
has
basic
information
at
this
point.
A
This
is
a
a
Java
project
that
I've
have
constructed
that
basically
just
has
a
bunch
of
code
in
it
very
very
few
things
I
have
thrown
in
some
code
in
there
that
would
cck
off
some
vulnerabilities
in
the
scans
just
so
that
there
is
a
way
that
we
can
actually
present
to
you
how
security
scanning
would
operate.
So
that's
the
Java
code,
U
subsequent
to
that
there
is
a
pom.xml
file
which
has
some
dependencies
in
it
very
minimal.
It's
a
it's
just
a
basic
project.
A
It's
a
Java
spring
project,
so
pretty
much
a
spring
dependencies
and
then
there's
the
ciml
file.
So,
let's
begin
by
examining
the
cimo
file
first,
when
we
look
at
the
cimo
file
the
way
I
have
structured,
it
is
there's.
There
are
stages.
We
have
a
build
stage,
a
test
stage,
a
deliver
stage
and
then
a
deploy
stage
so
deliver
stage
is
effectively
to
deliver
a
package
of
some
sort.
Maybe
a
runable
package.
A
Maybe
a
library
of
some
sort
that
sort
of
stuff
and
then
deploy
is
where
you
take
that
package
and
actually
put
it
out
into
the
server
and
start
it
up
to
run
it
I
will
skip
this
portion
right
now.
Needless
to
say,
this
is
a
static.
An
analysis
template
that
I'm,
adding
in
here
but
I'll
get
into
that
a
little
bit
more
So
within
the
build
stage.
I've
got
a
job
called
Maven
build.
It
basically
pulls
down
a
maven
image.
A
You
don't
have
to
do
this
if
you
are
running
the
runner
with
a
shell
executor
and
running
it
in
A
system
that
already
has
Maven
installed.
This
would
not
be
necessary,
but
in
my
situation,
I
am
actually
pulling
down
a
maven
container
and
then
building
it
within
the
container
and
that's
what
I'm
doing
here
so
the
script
basically
runs.
The
maven
verify
step
I
start
with
verify,
rather
than
build,
because
what
I
also
want
to
do
is
run
the
test
simultaneously
and
receive
the
test
reports.
A
So
I
have
actually
combined
two
things
in
here.
One
is
the
build
and
then
the
other
is
the
actual
test.
Now
further
to
that
is
I
have
bunch
of
rules.
The
rule
basically
identifies
that
this
needs
to
be
run
on
a
commit
branch,
and
it
will
always
be
run
at
that
point,
and
then
these
artifacts
will
be
pulled
up.
I
have
a
deploy
stage
which,
which
is
really
not
a
deploy.
A
It's
a
maven
deploy,
which
is
essentially
the
deliver
construct
that
I
described,
which
is
where
we
take
a
package
and
put
it
into
the
package
registry
within
gitlab,
which
is
what
I'm
using
right.
Now
you
could
put
it
in
any
package
registry,
but
that's
where
I
pointed
the
maven
process
to
go
to
so
I
run
the
maven
deploy
and
that's
where
that
would
go,
and
then
I
have
a
deploy
to
development
and
then
a
deploy
to
production.
A
Two
different
types
of
things
and
the
distinction
between
these
two
really
is
it's
the
same
process
it
it.
It
would
normally
take
this
package
and
deploy
it
out
into
your
development.
Server.
I
didn't
write
the
script,
but
if
you
want
to
you,
could
I
just
have
an
echo
statement
to
kind
of
present
to
you
the
the
fact
that
it
can
actually
operate
in
in
a
way
where
Dev
can
be
activated
at
certain
times,
and
production
can
be
activated
different
times.
A
Additional
thing
here
is
the
environment
setup,
where
I'm
actually
naming
the
environment
that
this
affects,
and
then
in
this
in
the
prod
I've
I'm
posting
it
to
staging
environment.
It
could
be
anything
staging
production
whatever
you
want
to
call
it
just
make
sure
that
the
name
here
matches
the
name
setup
in
the
environment,
so
I'll
get
into
the
setup
of
that
in
a
second
here
and
then
coming
back
to
the
static
analyzer.
A
This
is
where
gitlab
has
a
template
which
actually
runs
a
static
analysis
on
the
code
and
produces
the
results
it
attaches
itself
to
the
test
stage,
and
that's
why
I
have
the
test
stage
here
and
that's
where
it
would.
It
would
go.
I
spoke
about
environments.
Let
me
get
into
the
setup
pieces
of
how
to
get
this
thing
to
work.
A
But
in
our
case
what
we
have
done
is
essentially
put
Runners
into
specific
environments
which
are
doing
the
deployment
for
us.
So
let
me
get
into
the
runner
setup.
So
if
I
go
to
setup,
cicd
there
is
is
an
area
where
Runners
are
created
and
I've
created
two
Runners
runner,
one,
which
is
my
de
Development
Area
Runner
and
Runner
2,
which
is
my
production
area,
Runner
and
I've.
A
Given
it
a
tag
you
don't
have
to,
but
it's
useful
to
do
that
sometimes
also,
additionally,
I
have
protected
the
production,
a
runner.
Now
what
producted
does
is
essentially
it
signifies
that
not
anybody
can
use
this
Runner
for
any
kind
of
arbitrary
jobs.
Number
one
number
two,
only
jobs
that
come
from
protected
branches
would
be
accepted
in
here,
so
we're
sort
of
getting
into
the
trunk
based
development
model,
and
that's
what
that
would
do.
Setting
up
the
merge
request.
A
Approval
in
my
case,
I
have
created
an
approval
rule
where
there's
a
development
manager.
I've
chosen,
a
colleague
of
mine
as
the
approver
I,
have
made
it
a
zero
requirement,
but
this
could
be.
You
know.
However,
many
approvals
are
required
for
this
merge
request
to
approve,
in
addition
to
that,
get
lab
ultimate
I
could
enable
security
approvals.
I
have
not
set
that
up,
because
the
expectation
is
that
the
customer
does
not
have
gitlab
ultimate,
but
if
they
did,
what
could
happen?
A
Is
you
could
put
a
threshold
of
what
sort
of
number
or
what
sort
of
types
of
vulnerabilities
show
up
and
therefore
throw
in
an
addition
approval
on
top
of
the
ones
that
are
listed
up
here
dynamically
for
a
merg
request,
if
necessary
to
own
the
risk
for
those
vulnerabilities,
so
that
aside
moving
up
into
running
of
the
pipeline?
So
if
I
go
to
pipelines
the
way
that
the
pipeline
would
operate?
A
If
it
were
on
my
main
branch,
this
I'll
just
go
ahead
and
run
it
to
show
how
that
would
operate
so
I'm
running
it
on
the
main
Branch
I
run
the
pipeline,
and
essentially,
what
it
does
is.
It
will
create
the
all
the
jobs
that
it
needs
to
create,
so
it
will
have
the
maven
build.
It.
Has
the
semra
SAS
static
analysis?
It
will
then
perform
a
deploy,
meaning
if
all
these
things
are
okay,
it's
going
to
go
into
deploy
stage
from
there.
A
The
maven
deploy
essentially
is
the
deliver
stage
right
and
then
the
deploy
stage
is
where
it
actually
puts
this
package
into
the
development
environment
and
production,
environment
and
I've
got
them
stacked
in
that
order,
because
I
want
the
development
environment
to
automatically
get
the
package,
but
the
production
environment
would
require
an
approval
so
notice.
There
is
a
way
to
cancel
this
job,
but
there
is
no
way
to
cancel
this
job.
It
h
requires
a
manual
intervention
and
an
approval
before
it
will
move
forward.
A
So
while
the
pipeline
is
running,
what
I
want
to
do
is
actually
construct
a
merge
request
and
show
you
how
it
would
operate
when
we
are
modifying
some
code
within
a
within
a
branch,
so
I'll
go
ahead
and
create
a
branch
first
right.
So
this
is
the
development
process
I'm
going
to
create
a
branch
I'm,
creating
the
branch
so
there's
my
Branch
created
I
will
go
ahead
and
create
a
merge
request.
On
top
of
it.
Maybe
I
have
some
description.
I
can
then
I
go
ahead
and
create
the
merge
request.
A
So
once
the
merge
request
is
created,
a
pipeline
will
automatically
get
created.
On
top
of
that,
merge
request,
because
we
just
essentially
branched
off
of
our
base
code
and
that
pipeline,
as
you
will
see,
looks
a
bit
different
than
the
one
that
came
from
our
main
and
what
that
looks
like
is
essentially
does
the
build.
It
runs
the
static
analyzer
and
it
essentially
deploys
to
development
notice.
A
There
are
a
couple
things
missing:
one
is
creating
the
package
putting
it
into
the
package
registry
because,
presumably
all
you're
doing
here
is
modifying
some
code,
and
this
is
a
sort
of
a
a
transient
build
you
are
all
you're
wanting
to
do
is
to
get
something
into
your
development
environments.
You
can,
you
can
play
around
with
and
you
can
go
through
that
life
cycle
end
number
of
times
so
anytime
you
commit
code,
this
pipeline
would
run
and
it
would
deploy
to
development.
A
So
what
I
will
do
here
now
is
I
will
actually
go
ahead
and
edit
this
code,
I,
have
multiple
ways
of
doing
that:
I'm
going
to
use
the
web
IDE
for
the
moment,
because
that's
the
simplest
way
to
get
there
and
I'm
not
really
going
to
change
anything
big
in
the
code.
I'm
just
going
to
modify
the
read
me
file,
that's
enough
for
now
just
going
to
put
that
in
there
I'm
going
to
put
a
commit
message,
so
not
a
very
good
one,
but
it's
useful
for
what
I'm
doing
right
now.
A
So,
as
you
can
see,
it
will
commit
that
change.
It
is
committing
that
change
into
my
Branch.
And
now,
if
I
go
back
over
here,
you
will
notice
that
a
pipeline
was
constructed
and
things
are
starting
to
change.
In
the
view
of
the
merge
request
notice,
these
widgets
were
not
present
at
the
time
prior
to
changing
the
code,
but
now
they
are-
and
in
this
case
the
approval
has
showed
up
over
here.
There's
my
development
manager
approval.
A
Naturally
it
is
optional,
like
I
mentioned,
I
made
it
optional,
but
you
could
put
a
required
approval
and
how
many
you
might
need,
but
for
the
purpose
of
that,
this
demonstration
I
made
it
optional.
What
you'll
notice
is
the
pipeline
is
operational
at
this
time.
Once
again,
it's
only
doing
the
three
steps
that
I
mentioned.
Previously,
it's
doing
a
build,
it's
doing
a
static
analysis
and
then
it's
just
going
to
deploy
to
development.
So
the
pipeline
is
completed
over
here
now.
Couple
things
to
note
note
that
Maven
build
occurred.
A
Remember
that
the
maven
build
process
essentially
ran
ver
in
my
case,
I
do
have
multiple
tests
in
there
and
there's
my
test
results
for
the
maven
build.
You
can
see
those
three
tests
were
run.
What
the
status
was,
how
long
they
took
and
I
can
look
at
some
details
if
I
wanted
to
additionally,
because
I
have
G
laab
ultimate
I
have
the
security
tab
available
where
all
the
security
results
are
posted.
A
A
It
is
srat
sast,
there's
one
file
available
and
that's
the
GSS
report,
so
you
can
always
pull
that
one
and
view
it
and
see
what's
going
on
in
there,
so
that
information
would
become
available
for
you
from
a
static
analysis
perspective
and
then
not
that
the
deploy
job
is
there
anyway.
Now
stepping
back
into
the
merge
requests
that
I
have.
There
are
widgets
that
open
up,
as
you
can
see,
there's
the
pipeline
there's
the
approval
which
I
described
previously
is
the
development
manager.
A
In
my
case,
a
test
summary
does
show
up,
because
I
do
have
three
tests
and
then
it
actually
does
present
the
three
step.
Three
tests
I
also
have
the
security
scanning
widget
open
up,
which
for
people
who
don't
have
U
ultimate,
this
wouldn't
be
of
value,
because
there
would
be
nothing
here.
As
you
can
see,
the
merge
request
is
ready
to
be
merged.
So
when
I
mark
this
as
ready
and
subsequently
merge
this,
so
presumably
somebody
approved
it
and
all
that
stuff
has
happened
and
I
go
ahead
and
merge
this.
A
What
will
happen
is
so.
This
was
the
first
approval
over
here
and
the
second
approval,
which
is
the
pipeline
approval,
is
where
this
happens.
So
this
particular
merge
request
is
merg
and
what's
happening.
Is
it
created
a
pipeline?
You
can
go
examine
the
pipeline
in
detail
and
notice.
In
this
same
merge,
request,
post
merge,
you
are
getting
five
jobs
show
up,
which
is
the
build.
A
The
static
analyzer,
the
new
one
that's
been
added,
is
the
maven
deliver
and
then
the
de
develop
sorry
deployment
to
development
and,
in
addition,
deployment
to
production,
and
so
here's
the
pipeline
that
has
completed
now.
As
you
can
see,
the
build
process
completed
the
static
analysis
process,
completed
delivery
occurred,
deployment
to
development
occurred
anyway,
which
it
would
normally
have
and
deploy
to
production
is
ready.
I
cannot
click.
This
I'm
not
authorized
to
run
this
job.
A
It's
actually
scripted
to
deliver
the
package
and
run
it,
but
I
don't
have
access
to
do
it
in
a
staging
or
production
like
environment
by
way
of
protected
environment.
I
have
protected
it,
so
only
a
protected
Runner
can
run,
and
only
a
person
who
is
approved
to
allow
that
happen
has
to
approve
it
before
it
moves
on
forward,
so
that
kind
of
makes
the
whole
life
cycle
manageable.