►
From YouTube: Hands -On GitLab CI Workshop - EMEA
Description
Watch the playback for a hands-on CI workshop, in which you will learn how to build simple GitLab pipelines and work up to more advanced pipeline structures and workflows, including security scanning and compliance enforcement.
A
Good
afternoon
folks,
my
name
is
Steve
Graham
I'm,
a
customer
success
engineer
with
gitlab
I've
got
two
of
my
peers
in
this
webinar
with
us.
This
handzone
Workshop,
Morgan,
Lily
and
Justin
Conrad
are
here
they're
here
to
be
able
to
answer
questions
that
you
might
have
and
by
the
way,
if
you
have
a
question,
please
use
the
Q
a
functionality
we
do
have
the
chat
functionality
enabled
here
too,
to
give
everybody
a
chance
to
just
make
comments
is
appropriate
necessary.
A
So
we've
got
quite
a
few
folks
joining
today
and
I'm
really
glad
to
see
that
the
we're
going
to
get
underway
here
in
just
a
second
I've
got
a
couple
of
things.
I
wanted
to
share
with
you
today's
Hands-On
session
is
we're
going
to
be
walking
through
a
fair
portion
of
what
you
have
a
chance
to
complete
during
the
course
of
this.
A
This
assignment
that
you're
going
to
be
taking
on
there's
also
going
to
be
some
optional
material
that
we'd
really
like
for
you
to
review,
but
we're
going
to
go
ahead
and
get
started
with
this.
The
optional
content
is
going
to
go
to
to
security
and
compliance
and
gitlab
and
understanding
how
those
tools
work
during
the
course
of
today's
session
you're
going
to
get
provisioned
a
gitlab
ultimate
group
at
gitlab.com.
This
could
be
really
important
that
you
have
at
gitlab.com
registered
user
that
you
can
use
to
register
this
session
with.
A
A
All
right
and
again,
my
name
is
Steve
Graham
customer
success.
Engineer
at
gitlab
monitor
scale
team,
as
is
Morgan
and
Justin.
We're
proud
to
have
a
chance
to
take
this.
Take
this
content
on
this
is
our
agenda
for
today
we're
going
to
go
through
lab
setup
first,
which
is
going
to
be
the
provisioning
of
your
group
at
gitlab.com.
A
Then
we're
going
to
go
through
setting
up
a
simple
Pipeline
and
we're
going
to
get
into
execution
order
and
to
direct
it
to
cyclic
graphs,
we're
going
to
get
into
rules
and
failures,
we're
going
to
start
to
talk
about
SAS
testing
into
artifacts,
and
then
we're
going
to
show
you
how
you
can
transfer
the
project
out.
If
you
want
to
do
that
at
the
end
of
our
our
end
of
our
session
now,
just
for
awareness,
the
group
that
you're
going
to
have
set
up
at
gitlab.com
will
be
good
until
Saturday
on
Saturday.
A
A
All
right
so
today,
you're
officially
part
of
a
brand
new
startup.
It's
creating
a
public
leaderboard
the
hit
new
racing
game,
Tanuki
racing.
This
is
just
a
scenario
that
we're
playing
with
here.
Your
company
has
recently
swapped
over
to
using
gitlab
for
CI
and
CDN
is
testy
with
learning
about
the
different
pipeline
capabilities.
A
A
A
A
A
Now,
when
you
finish
that
process,
what
you're
going
to
end
up
with
is
this
right
here
now
the
important
thing
you're
going
to
want
to
do
is
you're
going
to
want
to
capture
this
this
URL
to
your
group
and
just
make
a
note
of
that
somewhere,
so
you
can
navigate
back
to
it
now.
Let
me
capture
this
and
we'll
just
go
ahead
and
start
this
process.
A
And
then,
once
you
get
this
here
capture
this
URL
and
make
a
note
of
it
somewhere,
but
you
can
go
directly
to
it
by
clicking
on
my
group
and
if,
for
some
reason
you
have
to
come
back
here
again,
it's
not
going
to
reprovision
a
second
group
for
you.
If
you
go
through
this
whole
process,
again,
it's
going
to
provision
exactly
the
same
group
for
you
and
you'll
end
up
seeing
a
group
that
looks
a
lot
like
this.
A
A
A
A
So,
let's
start
the
process
of
setting
up
a
simple
pipeline
before
fully
pushing
out
the
application.
Your
team
wants
to
test
a
few
different
types
of
pipelines
to
see
what
fits
their
needs
best.
The
first
task
your
product
manager
gives
you
is
to
create
a
simple
pipeline
that
builds
and
tests
the
racing
application
you're
going
to
need
to
navigate
to
this
project.
So
let
me
capture
that.
A
A
All
right
Adrian,
let's
just
keep
working
on
that
I'm,
going
to
go
ahead
and
move
ahead
here,
but
you
can
come
back
to
this
later
and
if
we're
not
able
to
get
it
set
up
during
the
course
of
the
session
today,
you
know
feel
free
to
reply
to
one
of
our
emails
and
let
us
know
and
we'll
see
if
we
can
we'll
see
if
we
can
help
you
out
so
for
any,
you
should
be
logged
in.
That
would
make
sense.
A
A
A
Now
the
next
thing
we're
going
to
do
is
we're
going
to
remove
the
fork
relationship
this
when
you,
whether
you
Fork
the
project
gitlab,
is
going
to
at
least
try
to
report
back
to
you.
Changes
in
yours
versus
changes
in
the
in
the
forked
version
and
so
to
to
just
free
ourselves
of
that
inhibition.
We're
just
going
to
remove
the
fork
relationship,
you're
going
to
go
to
settings
General
scroll
down
and
expand
the
advanced
section.
Then
click
on
remove
Fork
relationships.
So
that's
going
to
look
like
this.
A
A
A
We
have
a
build
stage
with
one
job.
We
have
a
test
stage
with
two
jobs
in
it.
We
have
a
deploy
stage
with
just
one
job
in
it.
One
thing
to
know
about
gitlab
Pipelines
in
general
and
CI
and
CD
is
that
all
jobs
in
this
stage
must
complete
successfully
before
proceeding
to
the
next
stage.
So
build
has
complete
before
test
a
and
b
can
run
the
test.
A
and
b
have
to
run
complete
before
deploy
can
run.
A
The
other
thing
to
realize
is
that
gitlab
jobs
run
independently,
sometimes
on
different
Runners,
but
the
good
thing
about
this
is
that
you
have
a
lot
of
bandwidth.
So
if
you've
got
a
moderately
large
Runner
Fleet
like
we
do
at
gitlab.com,
which
is
of
course
the
Manson
huge,
you
know,
there's
generally
lots
of
lots
of
Runners
ready
to.
A
A
Whatever
else
you
need
to
do,
although
if
you're
doing
that,
it
probably
makes
sense
to
start
building
out
your
own
Docker
containers
and
storing
those
in
your
Repository,
the
script
is
actually
the
contents
of
the
job
itself
and
then
the
after
script
is
a
chance
to
kind
of
run
some
cleanup
stuff.
If
you
need
to
do
that
afterwards,
so
the
important
thing
to
realize
is
that,
if
something
fails
in
your
before
script,
that's
going
to
fail
your
job.
A
A
A
B
A
And
this
is
a
this:
is
the
issues
that
we're
going
to
be
working
to
today,
there's
two
more
at
the
very
top
that
are
optional,
so
let's
go
ahead
and
take
a
quick
minute
kind
of
look
at
what
that
looks
like
in
a
split
screen
kind
of
bug.
Now,
I'm
sharing
a
screen
of
mine
and
I've
got
it
in
split
screen
mode
so
that
we
can
kind
of
put
these
things
together.
A
And
this
is
actually
what
you're
going
to
see
when
you
go
to
that
when
you
go
to
that
issue
list
again,
number
six
and
number
seven
are
optional,
but
there's
those
are
for
follow-up.
That's
part
of
the
reason
we
usually
give
people
two
days
with
these
provisioned
ultimate
groups,
but
in
this
case
we're
giving
you
four
and
the
reason.
Why
is
we
want
you
to
have
time
to
dive
into
the
optional
content?
If
you,
if
you
deem
that
appropriate.
A
So
we've
already
got
a
gitlab.ci.wordml
file.
This
is
the
default
name
for
a
a
Project's
pipeline
definitions.
Now
you
can
also
use
multiple
files
if
you
need
to,
and
we
have
methodologies
for
being
able
to
include
files
from
the
SQL
file
if
you,
if
you
need
to
take
that
route,
but
in
this
case
it's
all
built
into
one.
A
B
A
To
use
the
let's
see,
we
only
have
two
stages
to
find
building
tests,
so
remember
that
those
vertical
columns
we're
looking
at
in
the
pipeline
that
was
on
our
screen.
Previously.
We
only
have
two
defined
here,
build
and
test
in
the
in
the
unit
test.
So
let's
find
unit
test
there.
It
is
right
there
you
want
to
Define
an
after
script.
A
I'm
going
to
be
editing
the
pipeline
editor,
this
is
available
to
all
of
you
by
the
way.
I'm.
Sorry
I
got
a
little
bit
ahead
of
myself
here
and
I
apologize
for
that,
but
I
wanted
to
share
with
you
that
the
instructions
that
are
in
here
assume
that
you're
using
the
old
navigation,
if
you're,
gitlab.com
user
or
yourself
hosted
and
you're
on
16.
By
by
now,
you
probably
have
the
new
navigation
enabled,
but
I
want
to
show
you
how
you
can
quickly
change
that.
A
A
A
A
Right
so
after
showing
off
your
simple
pipeline
to
the
team,
they
loved
it
but
they're
wondering
if
you
can
switch
up
the
process
a
little
bit
now.
Remember
that
stages
have
to
complete
before
the
jobs
in
the
next
stage
can
run.
We
do
have
a
way
for
you
to
accept
that.
So
just
be
aware
of
that,
you
said
you're
going
to
show
off
your
skills
and
show
how
you
can
execute.
You
can
create
a
pipeline
with
different
execution
orders,
as
well
as
a
large
directed
acrylic
graph,
to
show
what
is
really
possible.
A
A
During
pipeline
execution,
these
jobs
are
getting
these
jobs
on
the
right
are
great,
because
they're
not
eligible
to
run
yet,
but
the
desired
state
of
this
CI
and
CD
execution
code,
quite
as
it
needs
results
of
build,
it
can
execute
parallel
and
we
want
to
keep
code
quality
in
the
test
stage.
So
there
is
a
way
to
accommodate
that.
A
And
that's
what
this
needs
directive,
so
the
code
quality
job
that
you
see
on
the
left
here,
foreign.
This
needs
keyword
with
an
empty
array
in
it.
That's
a
yml
array.
That's
empty
right
there
by
the
way
that
that's
you
can
actually
say
it
needs
Bill.
If
you
want
to
do
that,
but
since
it's
in
the
subsequent
stage,
we
don't
have
to
do
that
because
the
build
stage
is
going
to
have
to
complete
before
the
test
stage
starts.
A
A
A
A
A
Now
you
can
actually
build
stageless
pipelines
if
you
want
to.
If
you
want
to
declare
needs
in
every
single
job,
you
can
take
that
route.
I,
don't
recommend
it.
It
just
makes
it
easier
and
more
organized
to
be
able
to
have
the
stages
out
in
front
of
you.
So
you
understand,
you
know
jobs
by
category
type,
type
of
stuff.
A
A
So
why
is
this
useful
status
pipelines
make
your
pipeline
more
efficient
and
again
I
prefer
to
keep
them
in
stages.
But
that's
you
know.
Potentially,
if
you
have
a
pipeline
that
you
can
completely
100
Express
with
needs,
you
could
potentially
make
it
more
efficient
that
way
and
then
you
would
go
to
CI,
CD,
editor
and
you'd
be
able
to
deploy
the
needs,
keyword
on
all
the
jobs
and
just
to
clear
the
jobs
that
they're
dependent
on.
A
B
A
A
A
A
As
you
come
back
to
the
team
and
show
them
your
new
pipeline,
you
know
so
one
of
your
test,
jobs
is
failing.
After
taking
a
look
at
the
job
is
determined
that
you
don't
actually
need
to
enforce
it
passing,
but
still
want
to
see
the
results.
The
special
section
will
show
you
how
to
use
the
rules
and
failures
Clauses
in
your
gitlab
Pipelines.
A
A
A
When
is
the
job
created
in
a
pipeline,
this
is
important
to
know
and
has
to
do
with
allow
failure
if
a
job
at
jobs
included
in
a
pipeline
for
real
evaluates
to
true
and
has
a
clause
of
going
on
success
when
delayed
or
win
own
these.
So
when
on
success
means
if
everything
passes
and
or
is
allowed
to
fail
up
into
the
point
that
that
job
runs,
that
job
is
allowed
to
them
continue
to
run
when
delayed
means
start.
A
A
If
no
rule
is
defined,
but
the
job
has
a
default
clause,
so
rules
can
have
a
clause
of
going
on
success
when
delayed
and
when
always
but
soak
in
the
job
itself.
It
doesn't
have
to
be
inside
the
role
section
that
could
just
be
the
default
for
the
job
and
as
long
as
one
of
those
is
defined
in
the
job,
even
if
it
doesn't
have
a
real
job
will
get
inserted
in
the
pipeline
and
then
the
rule
is
defined
in
the
when
Clause
is
specified,
then
gitlab
is
going
to
default
to
win
on
success.
A
Scott
allow
failure
can't
be
used
in
the
before
scripts.
That's
that's
not
part
of
the
before
script,
but
you
put
it
in
the
job
itself.
It's
a
it's
a
it's
a
property
at
the
job,
and
if
you
make
that
the
property
of
the
job,
then
the
job
will
give
you
that
orange
exclamation
point
and
it
won't
stop
preceding
jobs
from
right
or
post
jobs
from
running.
A
So
in
this
particular
case,
we're
illustrating
evaluating
from
when
a
job
runs.
We've
got
a
we've
got
a
rule
in
here
in
the
FCI
pipeline,
Source
equals
equals
web.
Now.
What
that
means
right?
There
is
on
the
pipelines
page
for
a
project.
You
have
a
run
pipeline
button
and
if
you
use
that
run
pipeline
button,
that's
what
the
web,
what
that's
what
this
web
is.
So
this
is
a
job.
A
A
If
something's
changed
in
this
directory
or
this
file
or
this
recursive
directory,
then
this
job
should
run
or
if
a
file
exists,
that's
what
they
exist
as
if
that
file
exists
and
this
job
should
run
and
then
the
operators
that
you
can
use
when
you're
comparing
variables
to
values
you've
got
the
equals
equals,
which
is
what
you
think
it
is
the
not
equals,
which
just
means
you
know
not
equal
and
then
you'll
notice.
These
two
that
have
the
tilde's
in
right
here
and
sorry
keep
clicking
on
that.
Those
are
regex.
A
So
these
two
that
have
the
tilities
in
them.
That
would
be
not
equals
and
that
would
be
equals,
but
you
can
use
regex
patterns.
If
you
want
to
do
that
and
then,
when
you
need
to
join
conditions
together,
you
can
do
that
with
the
end
and
symbols.
So
you
can
do
one
test
on
the
left,
side
of
and
and
one
test
on
the
right
side.
Again
or
you
can
add
and
and
again
and
put
another
test
after
that,
and
then
all
three
have
to
be
true
for
it
to
complete
and
then
there's
the
oars.
A
The
pipe
symbols
are
just
orders,
and
typically,
if
you're
going
to
do
oars
and
ands
together,
you
would
put
the
ores
inside
of
parentheses,
so
you'd
have
the
s
or
test
inside
parentheses
and
then
and
end
something
else.
That's
kind
of
complete
and
then
job
attributes
are
when
allow
failure
and
start
in
starting
is,
is
a
you
know,
delayed
execution.
A
So
in
that
particular
case
you
can
specify
minutes
hours
days,
whatever
whatever
is
appropriate
and
then
allow
failure,
and
then
the
wind
options
are
always
never
on
success
on
failure,
which
is
an
important
thing
to
take
into
consideration.
If
you
have
a
failing
job
in
the
pipeline
and
something's
got
to
run
in
the
case
of
a
job
fairly,
to
maybe
do
some
inspection
or
do
some
testing
or
try
to
figure
out
what
happened.
A
You
can
do
an
unfailure,
it's
not
that
job,
but
only
fire
up
if
a
previous
job
was
not
allowed
to
fail
and
fail,
and
we
also
have
manual
manual
allows
you
to
actually
specify
if
you
use
via
the
project
settings,
you
can
actually
specify
who's
allowed
to
click
on
a
manual
job
in
a
protected
Branch.
So
then
you
can,
if
you
don't
fill
that
in
it
could
be
everybody.
Anybody
who's,
a
developer
on
the
project
and
is
eligible
to
run
a
pipeline
can
start
a
manual
Pipeline
and
then
delay.
A
A
We
don't
want
this
particular
job
to
run
if
the
pipeline
sources
a
merge,
request
event.
Whenever
pipeline
Source
SQL
schedule
whenever
and
then
it's
got,
this
default
rule
down
here
notice
that
each
one
of
these
dashes
is
an
independent
rule
and
the
default
rule
is
when
on
success.
So
if
it
doesn't
fulfill
one
of
those
two
previous
rules
that
its
default
rule
is
just
to
run
and
conditionally.
A
All
right
so
when
to
configure
for
manual
execution,
this
job
has
one
manual
and
you
can
see
that
it's
got
a
play
button
on
it.
The
play
button
will
initiate
show
showed
to
people
who
are
viewing
the
pipeline,
who
have
permission
to
run
it
now.
If
you
don't
specify
who
can
run
it,
then
anybody
who's,
a
developer,
can
run
it,
and
this
job
has
a
lot
of
failure
to
so
the
pipeline
proceeds,
even
though
it
failed
here.
A
Android,
can
we
see
that
pipelines
are
triggered
on
every
commitment
by
default,
and
can
we
change
this
Behavior?
You
absolutely
can.
So
if
you'll
do
a
quick
search
on
Google
for
gitlab
predefined
variables,
you'll
find
a
complete
list
of
our
variables
and
as
long
as
you
define
rules
that
only
match,
and
then
you
do
a
standalone
rule
of
whenever,
so
that
it's
got
to
match
a
rule
in
order
for
a
job
to
run,
then
then
that
would
cover
the
scenario
that
you're
talking
about.
A
A
So
CI
pipeline
source
is
one
of
our
predefined
variables.
That's
very,
very
important
it
really.
It's
got
a
very
long
list
of
things
that
can
create
a
pipeline
independently.
It
can
be
the
API,
it
could
be
a
scheduled
pipeline
that
gets
run.
You
know
it
can
be
run
manually
from
the
web
page.
It
can
be
a
commit,
it
can
be
a
merge
request,
and
so
all
of
these
things
are
opportunities
for
you
to
create
pipelines
that
run.
A
A
A
A
Anonymous
attendees
scheduler,
merge
request
is
in
the
current
commit
message.
These
are
actually
pipeline
triggers
that
come
from
git
Labs,
you
user
interface.
So
if
you
create
a
merge
request,
then
you
know
that's
a
an
opportunity
to
create
a
pipeline.
You
can
also
set
up
scheduled
jobs
to
run
automatically
and
get
lab
engine
projects
in
the
settings.
A
B
A
Now
variables
there's
a
lot
of
different
places.
You
can
create
variables,
you
can
put
them
in
your
gitlab
desky.yml
file.
You
can
put
them
in
the
project
that
can
be
inherited
from
the
group
The
Project
descends
from
if
you're
running
a
manual
pipeline
you
can
put
them
in
in
the
manual
pipeline
run
page
if
you're
doing
the
API
or
scheduled
you
get
the
opportunities
to
do
the
same
thing.
A
So
it's
good
to
know
the
The
Inheritance
inheritance,
precedence
right,
so
predefined,
environment
variables
are
down
here
at
the
very
bottom,
and
highest
is
the
ones
that
wins
deployment
variables.
So
something
that
you
is
running
in
a
job
itself.
I
will
define
global
variables,
job
level,
variables
inherited
environment
variables,
and
you
can
create
variables
that
are
just
in
an
environment
on
your
project
settings.
It
can
be
just
for
production,
it
can
be
just
for
staging
whatever
you
need
it
to
be.
A
If
you
have
Southwest
gitlab,
you
have
the
ability
to
create
variables
at
the
instance
level
that
come
next
and
then
group
level
variables
come
after
that
and
then
project
level,
variables
or
protected
variables
come
after
that
and
then
the
trigger
variables
and
scheduled
pipeline
variables
and
menu
pipeline
room
variables.
So
this
is
the
the
Precedence
and
it's
a
good
thing
to
note.
B
A
B
A
A
B
B
B
A
A
So
after
you
fixture
of
your
pipeline
and
run
smoothie
again
and
execs
stop
by
and
check
in
on
the
progress
we
want
to
make
sure
you're,
taking
full
advantage
of
all
the
future.
Skit
lab
is
offering
like
security
scanning
plus
artifacts
and
ask
if
you
can
demo
this
in
a
pipeline
during
the
next
stand
up
so
configure
access
manually
to
enable
SAS.
You
must
include
the
zest.
A
Sas.Getlab.Ca.Windl
templates
provided
as
part
of
your
gitlab
installation.
You
can
see
the
syntax
Port
right
there
on
the
screen
so
including
this.
This
is
not
inside
of
a
job.
This
is
just
generally
as
an
in
the
global
section
of
your
I
tend
to
put
them
at
the
bottom
little
section
of
your
git.ci.iml
file,
and
if
you
put
it
there
it'll
automatically
configure
that
job
for
you,
which
is
really
convenient.
A
So
what
is
the
template
in
gitlab's
case?
It
include
statement
that
has
the
keyword
template
on
it
means
that
that
template
is
something
that
shipped
with
gitlab.
You
can
also
create
templates
of
your
own,
but
they
use
a
different
syntax.
They
would
use
a
project
and
and
file
syntax
instead
of
using
the
template,
syntax
and
so
just
be
aware,
it's
it's
absolutely
possible
to
build
your
own
Banks
of
custom,
CI
and
CD
code.
That
applies
to
your
projects,
put
them
into
a
project
that
everybody
has
access
to,
and
you
know
we've
got
stuff
hosted.
A
It
could
be
an
internal
project
which
is
the
equivalent
of
public
to
everybody,
who's
logged
in.
If
it's
a
gitlab.com,
we
don't
have
that
internal
option
available,
it
would
have
to
be
public
or
you
would
have
to
make
sure
that
all
the
users
who
can
run
those
pipelines
and
other
projects
are
invited
to
that
project
at
at
least
the
reporter
level.
A
You
know
it's
a
again:
it's
something
that
ships
with
gitlab
itself,
but
this
is
a
way
for
you
to
share
cinc
capabilities
with
other
teams
in
New
York.
It's
a
way
to
consume
CI
and
CD
capabilities
from
other
teams
in
Europe,
so
you
can
have
a
team
that
focuses
on
pipelines
and
getting
them
functional
and
then
mix
them
in
a
way
that
could
be
used
by
other
projects
and
the
way
that
gitlab
engineering
provides
capabilities
via
templates.
So
we,
our
templates,
that
we
ship
with
gitlab
there's
nothing
magic
in
these
at
all.
A
These
are
100
code
they're
available
we're
we're
an
open
core
project
so
to
delineate
between
that
and
open
source.
Github
eer
Enterprise
Edition
is
open
core.
You
can
see
the
code
anytime
you
want
to,
but
it's
not.
It's
not
open
source
hasn't
free
to
use,
but
there
is
a
gitlab
CE
that
is
open.
Source
free
to
use,
but
together
be
is
open
course.
So
it's
always
there.
A
So,
including
templates
from
either
another
project
or
from
gitlab's
core
templates
ship
with
gitlab
use,
include
statements
again.
I
tend
to
put
these
at
the
very
bottom
of
gitlab.sci.yml,
and
that
way
they
were
gitlab's
going
to
pull
in
all
of
the
included
files.
You
know
before
it
starts
processing
it's
going
to
pull
in
all
the
included
files.
It's
going
to
merge
them
all
together
into
one
large.
B
B
A
Include
template
again
is
something
that
ships
with
kitlab,
which
is
not
to
stop
you
from
creating
your
own
top
templates.
They
just
use
a
different
syntax.
These
are
included
in
the
core
of
gitlab
itself
and
when
you
get
that
knows
that
when
you
use
the
template,
it
knows
where
that
keyword.
It
knows
where
to
go.
A
To
get
those
those
jobs
from
you
can
include
a
file
I
actually
call
this
include
project
but
you're,
actually
putting
a
a
path
relative
root,
a
relative
path
from
the
root
of
your
gitlab
business,
whether
it's
self-hosted
or
gitlab.com,
and
and
then
you
delineate
the
file
that
you
want
to
use.
That's
in
that
project
and
that's
how
you
would
use
templates
that
you
create
yourself
and
then
there's
include
locals.
So
you
might
have
an
instance
and
I
frequently
do
this.
A
I
can't
tell
you
how
much
of
this
I
do
I'll
create
a
pipelines
directory
in
my
projects
and
I'll
put
the
individual
pipeline
types
that
need
to
run
in
there
and
I'll.
Make
them
include
statements
that
use
this
local
syntax
then
just
also
include
remote.
Now
this
one's
a
little
bit
dicier.
But
let
me
just
explain
what
it
is
include
remote,
there's
no
authentication
on
this
at
all,
but
it's
gonna
it's
going
to
go
to
an
HTTP
or
https
address.
A
So,
let's
talk
about
some
options
from
customizing
job
behaviors
template
jobs
can
be
extended
right,
so
any
job
that
you
declare
in
gitlab
can
be
declared
again
and
its
properties
can
be
overridden
and
in
gitlab
we
use
key
value.
Pairs
specified
in
the
job
in
the
local
git
lab
can
be
used
to
replace
the
default
Behavior
environment
variables
can
also
be
used
to
change
behaviors
based
on
value.
A
So
you
can
see
other
variables
here
in
the
global
section.
That's
not
a
job
variables
is
a
keyword,
and
it
just
lets
us
declare
variables
that
will
apply
to
all
jobs,
secure
analyzers,
prefix,
secure
analyzers
version,
secret
detection,
excluded
paths
and
then
in
the
secret
analyzer
job
we're
declaring
an
image.
A
So
look
into
gitlab
SAS
documentation
to
understand
what
variables
are
available
to
override.
You
can
also
look
at
the
SAS
template
itself.
If
you
want
to
hunt
that
down
and
take
a
look
at
it
and
you
can
actually
see
what
trigger
functionality
is
built
into
the
code-
and
you
know
we
again:
we've
got
the
variables
declared
on
the
right
side
there
in
our
gitlab
Dash,
CI,
Dot
or
email.
Actually,
that's
in
the
SAS
kitlab
Dash
CID
helpline.
A
Now
you
can
see
the
variables
to
clear
it
there
so
that'll
give
you
a
sense
of
kind
of
how
you
go
about
customizing
it
if
you
need
to
by
default.
Sas
is
going
to
use
pattern
matching
to
decide
what
language
scanner
so
SAS
covers
a
very
broad
range
of
languages,
and
it's
going
to
do
pattern
detection
to
try
to
determine
what
language
to
bring
in
and
use
and
remember
that
our
set
with
most
of
our
scanners.
A
A
A
Now,
let's
talk
a
little
bit
about
artifacts,
you
know,
artifacts
are
just
practice
life
when
you're,
creating
builds
and
and
the
like,
and
in
fact
our
security
scanners
create
our
facts
that
are
reports.
So
just
be
aware
of
that,
if
you're,
if
you
want
to
download
an
artifact
in
the
gitlab
UI
on
the
pipelines
page,
you
can
download
all
the
artifacts
that
are
associated
with
the
pipeline.
A
If
you
go
to
a
job
on
the
jobs
page,
you
can
download
all
the
artifacts
associated
with
the
job.
This
will
be
a
an
archive
file
and
then,
if
you
go
to
a
specific
job
on
its
job,
page
you'll
have
the
ability
to
do
the
same
thing.
You'll
be
able
to
download
from
there
but
see
that
there's
a
browse
button
here
and
the
artifact
browser
will
let
you
so,
let's,
let's
assume
that
you
create
a
job
and
it
creates
10.
A
Artifacts
gitlabs
can
archive
those
all
up
into
one
big
archive
file
and
with
the
download
button,
you'll
be
able
to
download
the
whole
thing
and
then
you'll
have
to
unarchive.
It
extract
what
you
need,
but
if
you
use
the
browse
button
it'll,
let
you
actually
pick
the
individual
things
you
want
to
download.
A
A
So
artifacts
this
is
good
behave.
This
is
good
best
practices
here
with
the
artifacts
we're
going
to
create
a
path
which
is
going
to
tell
gitlab
where
to
look
for
the
artifacts
and
we're
also
going
to
create
this
expire
in
now.
You
don't
have
to
create
this,
but
if
you
don't,
artifacts
can
become
immense
and
immersive
in
their
store
and
get
that
so
if
you're
self-hosted
or
if
you're
at
gitlab.com.
This
is
going
to
use
up
your
storage.
So
you
know
if,
if
there's
a
reasonable
period
of
time,
you
can
expire.
A
A
Let's
take
a
look
at
the
full
configuration
with
this
completed
notice
that
staff's
job
has
now
been
pulled
in
so
you're
looking
at
the
unified
object.
After
all,
the
includes
have
been
pulled
together
and
merged
together,
and
you
can
see
that
all
of
these
new
items
are
added
at
the
at
the
top
here
to
correlate
to
kind
of
section
where
it
was
where
it
was
included.
At.
B
B
A
B
A
A
A
B
A
B
A
B
A
Right
now,
the
last
thing
is:
if
you
want,
if
you
want
to
keep
this
project
after
we're,
done,
you're
going
to
need
to
transfer
it
to
a
namespace
somewhere
else.
So
in
that
particular
instance,
you
could
you
could
transfer
it
to
your
personal
namespace
at
GitHub.
The
thing
to
realize
is
that
this
is
a
gitlab
ultimate
project
and
group,
so
when
you
transfer
it
to
a
new,
you
know,
root
level
group
namespace
at
gitlab
or
to
your
personal
names,
basic
gitlab.
It's
going
to
be
limited
to
the
feature,
sets
that
are
there.
A
A
A
So
these
are
the
basic
instructions
now
I
want
to
make
you
aware
of
a
couple
of
other
things.
We
do
have
some
optional
content,
which
is
the
reason
that
we
are
allowing
you
to
keep
this
this
provision
group
until
Saturday
and
that's
the
optional
security
compliance
now
you're
going
to
go
through
a
process.
That
looks
a
lot
like
what
we
just
did
today
working
another
project
into
your
name
into
your
provision
group
and
then
following
the
issue,
queue
that's
in
it,
get
your
instructions.
A
And
you
know,
when
you're
working
with
this,
it's
going
to
cover
the
concepts
of
really
shifting
left
in
a
significant
way,
you're
going
to
get
a
chance
to
see
how
to
get
lost
compliance,
Frameworks
work
and
talk
about
parsing
the
results
and
getting
to
an
understanding
of
that
you're
going
to
get
to
where
you
understand
how
to
how
to
be
able
to
review
a
software
bill
of
materials
reports
and
license
compliance,
and
then
the
ability
to
create
on-demand
scans,
audit
events
and
extra
configurations
and
then
again
transfer
projects.
If
you
want
to
do
that,
foreign.
A
A
And
this
is
an
example
of
a
project
where
it's
got
multiple
independent
Pipelines,
so
this
just
basically
talks
about
setting
it
up.
If
you've
got
to
do
this,
one
of
the
key
parts
of
being
able
to
do
these
complex
testing
for
rules
and
being
able
to
execute
these
pipelines
as
rapidly
as
possible.
It's
getting
to
the
fastest
Runners
that
you
can.
This
particular
project
completely
dispenses
with
job
logic
altogether
and
it
uses
gitlab,
shell,
Runners
and
all
they're
doing
is
they're.
A
Every
single
job
runs
and
it
executes
an
EnV
command
to
pop
out
all
of
its
variables
so
that
you
can
see
what
variables
are
available
there-
foreign
in
this
particular
project.
So
let's
read
me
in
the
pipelines.
Give
you
a
sense
of
the
workflows
that
are
here
commits
to
the
main
branch.
Now
this
is
a
protected
branch
in
this
project,
so
commit
shouldn't
be
made
to
the
main
branch,
but
they
can
be
by
the
sres
and
special
users
that
know
exactly
what
they're
doing
and
need
to
resolve
a
problem
quickly.
A
Merge
requests
targeted
to
the
to
the
main
branch
you're
also
going
to
get
their
own
independent
pipeline
and
then
a
merge
commit
so
once
the
merge
request
has
been
approved
and
it's
now
being
merged
that
has
its
own
independent
pipeline
going
into
the
main
branch.
So
there's
tests
that
run
in
the
merge
request.
A
The
merge
request
is
a
re-emerged
with
with
the
the
main
branch
and
it
runs
that
way
by
virtue
of
the
settings
that
have
been
set
up
here
and
then
so
it's
running
all
these
tests
on
a
pre-emerged
result
set
and
then
once
those
tests
are
done
and
you
merge
it
as
it
merges
back
into
the
main
branch,
it's
got.
The
ability
to
run
a
deploy
if,
if
needed,
deploys
in
this
particular
project
require
an
approvals
so
they're,
not
just
automatic
they're
manual
jobs
and
people
have
to
go
in
and
approve
them.
A
So
that
keeps
you
know,
jobs
from
just
running
automatically
and
deploying,
for
example,
to
production
and
then
tags,
which
is
how
this
project
likes
to
release
code.
I
like
to
release
code
on
text.
You
know,
which
is
a
fairly
common
methodology
and
way
to
go
text
that
comply
with
the
naming
conventions
for
a
release
will
get
their
own
special
pipeline
texts
that
don't
comply
with
the
naming
for
release.
We'll
have
a
different
pipeline.
A
The
tags
that
have
a
release
I've
got
a
full
deploy
capabilities
and
then
this
particular
project
requires
that
they
test.
You
know
multiple
tags,
ones
that
they're
still
supporting
to
make
sure
that
they're
identifying
any
security
vulnerabilities
in
it
and
they
help
someone
a
test
made
periodically
the
the
main
or
Master
branch.
So
they
can
set
up
scheduled
jobs
and
there's
an
independent
pipeline
for
that.
A
B
A
Right
there
they
could
put
this
keyword
into
their
commits
and
this
will
look
for
those
and
if
it
finds
those
and
they're
not
in
the
main
branch,
then
it'll.
Let
them
do
the
X
cubes
of
the
a
couple
of
quick,
quick
code
tests,
and
then
this
project
also
requires
that
they
have
custom
pipeline
capabilities
so
via
the
API,
a
manual
interface
or
scheduled
jobs,
they
can
set
up.
A
A
A
Anything
going
into
Maine
is
considered
an
emergency
unless
it's
a
merge
request,
so
emergency
pushes
an
API
or
web-based
emergency
release,
and
then
anything
that
goes
to
production
is
going
to
have
these
Square
tags
here.
So
anytime,
you
see
the
score
tag
in
these
pipelines.
You
know
that
that's
going,
that's
got
the
ability
to
go
to
production
if
it's
approved,
and
then
you
have
various
other
types
of
jobs
are
identified
there
as
well.
So
just
be
aware,
this
is
a
good
example
project.
It
has
some
great
rules
that
you
can
look
into.
A
A
So
I've
run
us
a
little
bit
over
and
I
really
apologize
for
that,
but
we're
at
the
very
end
now
so,
we've
covered
all
of
our
stages
for
today,
I
really
seriously
apologize
for
the
runner
problem.
We're
going
to
hop
off
this
call
and
jump
on
to
that
immediate
and
see
if
we
can
get
that
resolved
as
rapidly
as
possible.
So
foreign.
A
Address,
if
you
can
reach
out
to
your
account
executive,
they
can
engage
one
of
the
customer
success
Engineers
to
come
in
and
see
if
we
can
help
you
on
this.
But
I
would
also
recommend
that
you
check,
with
our
support
team
Book
News
support
ticket
on
that
and
see.
If
you
can
help
to
resolve
that
particular
problem.
A
All
right,
so,
when
I
manually
trigger
a
pipeline,
it
is
prompting
to
key
in
any
variables
yeah.
It
does
do
that
and
you
can
add
variables
there
if
you
want
to
do
it,
but
you
can
also
pre-populate
variables,
there's
syntax!
You
can
use
in
your
gitlab
dash
ci.yml
to
declare
those
variables
give
them
a
default
value.
You
can
also
add
a
description
there.
So
people
know
what
their
value
options
can
be
if
they
want
to
do
it.
A
A
A
A
So
folks,
I've
read
this
over
by
five
minutes
today
and
I
really
apologize
for
that.
It
looks
like
we've
got
all
the
questions
answered,
so
please
do
take
the
time
to
look
at
the
optional
material
we're
going
to
dive
in
fix
the
router
problem
right
now
as
rapidly
as
we
can,
and
we
really
appreciate
you
taking
the
time
to
join
us
today.
So
that's
it
and.