►
From YouTube: Secure multi project pipeline integration for analyzers
Description
This video demonstrates how Secure group leverage multi project pipeline feature of Gitlab to test analyzers end to end.
A
You
can
already
include
those
jobs
in
analyzers,
so
let's
check
into
them
in
detail,
so
I
will
just
go
through
one
of
them
in
detail
and
other
one
is
the
pretty
much
the
same
logic.
So
this
is
for
dependent.
This
job
is
created
for
dependency
scanning
analyzers.
So,
with
the
multi
project
pipeline,
we
can
pass
some
variables
to
the
to
the
other
projects
pipeline
and
we
can
trigger
them.
So
we
disable
all
other
analyzers
that
accept
dependency
scanning,
because
when
we
run
the
pipeline,
four
defendants
is
scanning.
A
We
don't
want
other
analyzers
to
run
and
we
has
a
variable
that
we
let
we
use
in
our
dependency
scanning
configuration.
Basically
what
this
variable
says
that
use
the
image
here,
that's
defined
for
running
the
dependent
scanning
analyzer
and
we
will
just
trigger
the
master
branch
of
the
project.
We
gonna
fill
this
information
and
this
is
something
that's
poured
the
multi
project
pipe,
and
so
you
just
wait
that
pipelines
result.
A
So
if
you
go
back
to
this
diagram,
so
what
we
will
do
is
like
me:
gonna
created
a
job
that
will
extend
from
the
downstream
des
job
and
we're
gonna
put
the
project
that
we
want
to
trigger
so,
for
instance,
for
gymnasium
Python.
We
would
like
to
test
Python
PDF
and
Python
pip,
and
what
will
happen
is
that
gymnasium
pipeline
will
trigger
a
pipeline
for
Python
PDF
using
the
image
that's
built
for
that
branch
and
the
Python
people
will
report
the
result
of
the
pipeline,
and
if
that
pipeline
passes,
the
gymnasium
pipeline
will
pass.
A
So
I
just
fought
the
gymnasium
Python
into
my
own
space,
just
to
show
demonstrate
this
configuration,
but
it's
already
in
our
original
gymnasium,
Python
repo.
So
I
just
add
these
two
jobs
and
we
have
the
projects
that
we
want
to
test,
and
we
just
extend
from
that
to
think
that
we
defined
in
the
CI
templates
jobs
and
if
you
create
an
Emer,
what
happens
is
that
we
have
now
a
new
stage
called
downstream,
so
that
downstream
is
triggering
two
different
projects
and,
depending
on
their
result,
the
downstream
will
pass
or
fail.
A
So
if
you
look
at
the
pipeline
in
detail,
so
we
can
see
everything
is
pretty
much
the
same.
Apart
from
this
stage,
that's
introduced
and
this
two
jobs
for
the
test
project
will
run
and
their
results
will
affect
the
to
downstream
stage.
We,
and
this
will
run
for
branch.
This
will
run
for
masters
tagging
and
release
to
make
sure
that
we
have
end-to-end
integration
tests,
make
sure
that
our
analyzers
don't
break
if
they
are
included
in
a
test
project.
So
we
used
to
do
this
thing
manually
by
leveraging
this
variable.