►
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
Okay,
so
hello
and
welcome
to
today's
session
and
we're
going
to
be
covering
CI
using
gitlab
in
today's
Workshop
I'm,
just
going
to
go
over
a
couple
of
housekeeping
items
before
we
get
stuck
into
it
and
today
you're
all
going
to
be
provisioned
with
a
gitlab
ultimate
group
on
gitlab.com.
That
will
be
your
training
environment.
A
A
It's
also
worth
noting
that
you're
going
to
have
access
to
the
training
environment
that
we
provisioned
today
for
about
four
days
and
which
will
give
you
time
to
return
and
revisit
to
some
of
the
instruction
sets
that
we'll
walk
through
today
and
also
I,
have
my
colleagues
with
me
today
from
the
customer
success,
team
and
they're
here
in
the
Q,
a
section
of
zoom
and
they're
they're
ready
and
waiting
to
answer.
Any
questions
that
you
have
throughout
the
session.
A
I
would
ask
that
participants
stay
on
mute
during
the
duration
of
the
workshop
to
ensure
we
can
keep
the
the
flow
good
and
but
if
you
do
have
questions
as
I
said,
please
feel
free
to
fire
them
into
the
Q
a
section.
It's
not
the
chat
box
in
Zoom,
it's
actually
the
icon
beside
it
to
the
right
hand,
side
you'll,
see
q
a
and
one
final
thing
to
note
as
well.
A
Cool,
so
my
name
is
Justin
Conrad
I'm,
a
customer
success
engineer
here
at
gitlab,
I
work
on
this
scale
team
and
I
mostly
handle
our
emea
Enterprise
accounts
after
today's
session.
Please
feel
free
to
connect
with
me
on
LinkedIn,
or
you
can
take
a
look
at
some
of
my
contributions
on
gitlab.com
as
well.
A
If
we
take
a
quick
look
at
the
agenda
for
today,
so
first
we're
going
to
go
through
lab
setup
and
actually
provision
that
training
environment
on
gitlab.com,
then
we'll
go
through
the
setup
of
a
simple
pipeline
and
move
on
then
to
execution
order,
Dag
and
then
we'll
look
at
some
rules
and
failures
and
finally
SAS
the
artifacts
the
last
step.
There
you
see
of
transferring
the
project
it
will
be
optional
and
but
we'll
cover
that
at
the
end,
if
any
of
you
want
to
transfer
today's
project
out
of
your
training
environment
into
your
own
environment,.
A
A
So,
let's
get
started
now
with
your
lab
setup,
we're
going
to
begin
by
going
to
gitlabdemo.com,
which
I
will
now
paste
into
the
chat
for
you
all
to
copy
and
go
to,
and
when
you
get
there,
I
want
you
to
click
on
the
blue
button
that
says
redeem
invitation
code,
I'm
actually
going
to
do
it
here
as
well,
so
that
you
can
follow
along
with
my
steps
you
can
see
here.
I've
opened
up
get
that
demo.com
I'm,
going
to
click
on
this
blue
button.
A
A
A
I
also
just
want
to
show
you
this.
So
if
you
need
to
retrieve
that
username
on
gitlab.com,
this
is
the
old
UI.
It's
up
the
top
right
hand.
Corner
you'll,
see
the
icon
of
your
profile
image
in
the
new
UI.
It's
actually
on
the
left
hand
side,
but
regardless
click
on
that
icon,
you'll
get
this
drop
down
and
blow
your
name.
You
get
your
username
and
just
notice
that
we're
not
including
the
ad
symbol
here.
A
Great,
so
you
should
all
be
here
now.
This
page
here
is
pretty
important.
It
contains
a
link
to
your
training
environment,
so
this
link
here
I
would
recommend
that
you
all
copy
paste
it
keep
it
somewhere
safe
for
the
duration
of
the
workshop.
This
is
the
provisioned
training
environment
that
we'll
use
show
today
you
can
get
to
it
by
clicking
here,
or
you
can
also
click
on
my
group,
which
will
take
you
there
as
well.
A
A
If,
at
any
stage,
you
found
yourself
here
or
some
other
page
that
you
haven't
seen
up
on
my
screen,
you've
probably
hit
an
error
or
done
a
misclick
somewhere
along
the
way.
So
you
can
reach
out
to
my
colleagues
in
the
Q
a
section
they
should
be
able
to
get
you
back
on
the
right
track.
You
should
not
be
seeing
anything
like
this.
A
A
A
A
You
can
see
it
here,
so
you're
going
to
click
on
Fork
and
after
you,
click
Fork
you're
going
to
have
to
go
ahead
and
fill
out
some
details.
Now
the
first
one
will
be
this
drop
down,
so
you
can
leave
the
project
Name
by
default
in
this
drop
down.
You
can
paste
the
string
that
we
collected
in
the
previous
step.
So
after
my
test
group
in
your
training,
environment,
I
had
a
string
of
letters
and
numbers.
A
B
A
So
to
do
this,
we're
going
to
click
on
settings
in
the
left
hand,
menu
we'll,
get
your
hair,
so
we're
going
to
go
to
settings
and
we're
going
to
go
to
General
when
you're
in
general.
You
want
to
scroll
down
until
you
see
Advanced,
and
you
want
to
expand
this
out
and
in
here
you're
going
to
see
an
option
like
this.
A
Great
so
I'll
assume
that
we've
all
gotten
there
and
now
what
I'm
going
to
do
is
paste
in
a
link
again
to
our
chat.
If
we
can
all
follow
it,
this
link
contains
a
list
of
issues
and
those
issues
are
actually
our
instructions
that
we're
going
to
follow
for
today.
The
link
will
open
up
this
window
here
that
you
can
see
on
the
right
hand,
side
of
my
screen,
and
you
can
see
it's
broken
down
into
a
number
of
seven
different
issues.
A
Today,
we're
going
to
cover
one
through
four
five
will
be
an
optional
set
for
you
guys
to
transfer
the
project
out
of
this
training
environment
into
your
own
and
six
and
seven
will
also
be
optional
ones
that
you
can
work
on
in
your
own
time.
As
I
said,
you'll
have
the
trained
environment
for
another
four
days,
so
you
can
work
through
these
later
on
if
required.
A
A
We
just
take
one
or
two
minutes
here
to
make
sure
that
everyone
gets
to
this
stage
if
anyone's
struggling
or
if
you've
hit
any
issues
just
reach
out
to
us
in
Q
a
we
can.
We
can
assist
you
there,
let's
take
a
minute
or
two
to
get
us
up
to
speed.
A
Here
again
is
the
link
into
the
chat.
This
link
is
our
source
project.
This
is
the
one
that
we're
going
to
Fork
to
Fork
it
you're
going
to
click
on
Fork
up
in
the
top
right
hand,
corner
you
can
leave
the
project
name
as
is
in
here.
This
is
where
you're
going
to
paste
the
string.
That's
attached
to
your
test
group
this
one
here,
so
you
can
paste
that
in
there
you're
going
to
select
this
guy
and
then
you're
just
going
to
click
on
Fork
project.
A
A
Okay,
folks
I'm
going
to
keep
moving
here.
If
any
of
you
are
a
stoker,
have
any
issues
just
Richard,
my
colleagues
in
the
Q,
a
section
they're
there
to
help
you,
but
hopefully
you're
all
at
this
stage.
Now
we
can
move
forward.
A
A
A
A
So
now,
let's
take
a
look
at
Job
statements
in
this
job
name:
production
that
runs
in
the
deploy
function
stage.
You
can
see
that
the
before
script
and
script
statements
are
used,
so
you
can
see
before
script
here
and
script
here
whenever
you're
writing
jobs,
you
will
always
have
the
script
keyword
defined.
That's
this
guy
here
script
is
the
only
keyword
that
a
job
needs.
Without
it,
a
job
wouldn't
have
anything
to
do.
A
In
addition
to
script,
there
is
also
the
before
script
and
after
script.
Keywords
before
script
runs
before
the
script
statement,
but
in
the
same
shell,
as
the
script
statement,
its
main
purpose
is
to
run
any
steps
that
are
necessary
in
order
for
the
script
statement
to
execute
properly.
A
good
example
will
be
before
scripts.
Perhaps
installing
the
AWS
CLI
with
the
script
then
executing
some
AWS
CLI
commands
like
the
before
script,
there's
also
an
after
script,
which
is
optional
after
script,
runs
after
the
script
keyword.
A
So
you
can
also
evaluate
the
exit
code
of
script
in
after
script
and
have
additional
job
behaviors
depending
on
the
result.
From
a
pipeline
perspective,
a
job
is
evaluated
as
a
success
or
failure
based
on
the
exit
code
in
the
script
statement.
Only
so,
even
if
in
the
after
script,
if
you
have
a
success
or
failure,
that's
not
what
the
the
pipeline
perspective
is
from.
A
So,
let's
take
a
quick
look
at
gitlab
Runners,
a
gitlab
runner
is
an
application
that
works
with
gitlab
CI
CD
to
run
jobs
in
a
pipeline.
A
When
you
register
a
runner,
you
can
actually
add
tags
to
it
as
well,
so
that
when
a
cicd
job
runs,
it
knows
which
Runner
to
use
by
looking
at
the
assigned
tags
tags
are
also
the
only
way
to
filter
the
lists
of
available
Runners
for
a
job.
So,
for
example,
if
a
runner
has
the
Ruby
tag
like
this
one
here
does
you
would
add
this
code
to
your
projects.
Gitlabs
cei.yaml
file.
A
Okay,
so
now
let's
go
ahead
and
take
a
look
at
some
of
the
Hands-On
steps
and
I'll
post
this
link
again
to
you
in
the
chat
which
will
bring
you
to
the
issues
that
contain
our
instructions,
I'd
like
for
you
to
go
ahead
and
open
up
issue
number
one
which
should
be
labeled,
simple,
pipeline,
I'm,
going
to
do
the
same
up
on
my
screen
here,
so
you
can
see
and
follow
along
so
issue
number
one
simple
pipeline.
A
A
A
A
A
Sorry,
folks,
that
doesn't
seem
to
be
opening
there.
For
me
this
one
moment
there
we
might
need
to
open
it
up
in
the
web
ID
instead.
B
A
A
A
So
your
new
unit
test
job
should
look
like
this
in
completion.
If
you
like,
you
can
also
copy
this
and
paste
it
in
if
that
makes
it
easier
for
you
and
once
you've
edited
that
once
you've
added
in
those
data
after
script
keyword
and
this
step
here,
you
just
want
to
go
ahead
and
click
click
on
Commit
changes
which
will
be
down
the
bottom
of
your
pipeline,
editor.
A
A
A
A
So
we
were
at
the
stage
here
where
we
wanted
to
see
the
pipeline
run
after
we'd
made
the
the
changes
by
adding
the
after
script,
and
hopefully
you
can
all
see
that
your
pipeline
has
run
by
going
to,
in
the
left,
hand,
menu
build,
Pipelines
and
clicking
into
the
pipeline,
and
you
can
do
that
by
clicking
on
the
number-
and
you
should
see
this
so
you
can
see
here.
This
is
my
build
up.
A
Job
has
completed
and
my
unit
test
job
has
also
completed
if
we
click
into
unit
tests
and
scroll
down,
you'll
you'll
see
exactly
what
the
job
has
actually
done,
and
you
can
see
here
the
after
script,
so
we
added
this
after
script
and
exactly
what
we
wanted
it
to
do.
It
has
done
so.
It
echoed
out
build
that
job
has
run.
A
B
A
So
now
that
we
have
our
simple
pipeline
setup
and
after
adding
on
the
after
script
to
our
unit
test
job,
let's
talk
a
bit
slightly
more
advanced
scenario
with
job
execution
order
and
dikes,
and
then
we
can
get
into
another
Hands-On
example
in
our
lab
environment.
A
So
if
we
go
back
to
our
fictional
startup
scenario
and
after
showing
your
simple
pipeline
to
the
team,
they
loved
it.
But
they
want
to
know
if
we
could
speed
it
up
a
little
so
time
to
show
off
your
skills
and
show
how
you
can
create
a
pipeline
with
different
execution
orders,
as
well
as
a
large
directed
acyclic
graph,
to
show
what
is
really
possible.
A
A
So
what
about
adjusting
the
execution
order
of
a
pipeline
to
increase
efficiency?
The
pipeline
graph
shows
us
the
pipeline
stages
and
jobs
in
terms
of
execution
order.
In
this
scenario,
let's
imagine
that
the
QA
team
added
this
code
quality
job
to
the
test
stage.
You
can
see
the
job
here
above
the
unit
test
job
in
the
image.
A
So
how
do
we
adjust
the
job
execution
order
of
this
code?
Quality
job?
We're
going
to
look
at
this
now
by
using
the
neat
keyword
as
we
speak
about
code
quality
as
well?
It's
probably
worth
mentioning
that
gitlab
has
a
code
quality
template
that
can
also
be
used
and
will
cover
the
use
of
templates
later
in
an
upcoming
section.
A
A
This
keyword
allows
us
to
specify
which
jobs
need
to
run
before
the
job
can
start
by
leaving
this
neat
keyword
value
empty.
We
are
asserting
that
this
code,
quality
job
can
be
run
as
soon
as
the
pipeline
begins,
that
is
to
say
that
it
doesn't
need
to
wait
for
any
other
job
to
complete
before
it
can
start
in
step.
Two
of
our
Hands-On
tasks,
we'll
actually
work
with
this
neat
keyword
and
you'll,
get
to
see
it
in
action.
A
A
A
A
A
A
A
But
what
if
we
wanted
two
jobs
to
run
in
parallel?
We
can
do
that
with
the
needs
keyword.
So
we
need
to
go
back
to
our
gitlab
CI
yaml
file.
So
if
you
go
back
to
the
root
our
gitlab
ciml
file.
B
A
A
So
now
that
we
have
the
two
jobs,
we
also
want
to
modify
the
execution
order
so
that
they
run
at
the
same
time.
We
don't
want
one
waiting
for
the
order,
so
in
the
unit
test
job
we're
going
to
add
the
needs
keyword
here,
So
Below
after
script,
we
just
want
to
add
the
neat
keyword
right
there.
You
can
do
so
by
just
copy
here
and
paste
it
in
below
the
after
script
keyword.
A
And
what
you
should
see
is
that
both
jobs
actually
run
at
the
same
time,
so
you're
no
longer
waiting.
You
should
see
that
the
code
quality
job
kicks
off
and
runs
because
we
added
in
that
needs
keyword.
A
A
B
A
A
A
But
this
is
essentially
what
it
should
look
like.
It's
far
more
complicated
than
what
we
had
previously
it's,
because
we've
added
in
all
of
these
jobs-
and
you
can
see
here-
if
you
click
on-
needs,
you're,
going
to
generate
this
graph.
It
shows
you
exactly
what
needs
what
so
we
can
see
the
test
a
need
to
build
a
to
complete
before
deploy
a
can
finish
or
even
start,
and
this
is
a
visualization
we
were
talking
about.
A
We've
seen
some
of
these
that
are
hugely
complicated,
but
if
you
take
over
a
project-
and
this
is
already
done-
it
makes
it
super
simple
to
track
back
and
see
the
relationships
between
jobs.
A
If
we
go
back
to
our
pretend
scenario-
and
you
notice
that
one
of
your
test
jobs
is
failing
after
you
look
into
the
job,
it's
determined
that
you
don't
actually
need
to
enforce
it
passing.
But
do
you
still
want
to
see
the
results
from
it?
So
now,
in
this
section
we
will
look
at
how
you
could
use
rules
and
failure.
Clauses
in
your
gitlab
Pipelines.
A
To
achieve
this,
we
can
use
the
allow
failure,
keyword
on
a
job
setting
deal.
Okay
failure,
keyword
with
a
value
of
true
means.
The
subsequent
jobs
will
still
continue
to
execute.
Even
if
this
job
fails
in
the
example
here
you
can
see
that
we've
set
the
allow
failure,
keyword
value
to
true
down
here,
so
that
if
this
unit
test
job
fails,
the
subsequent
jobs
will
still
execute
you'll,
always
see
failed
jobs
showing
your
pipeline
with
this
Amber
exclamation
mark,
like
you,
can
see
here.
A
So
when
the
new
pipeline
starts
gitlab
checks,
the
pipeline
configuration
to
determine
which
job
should
run
in
that
pipeline,
you
can
configure
jobs
to
run
depending
on
many
factors
like
the
status
of
variables
or
the
pipeline
type,
to
configure
jobs,
to
run,
depending
on
sorry
to
configure
a
job
to
be
included
or
excluded
from
certain
pipelines.
A
In
terms
of
evaluating
when
a
job
runs,
it's
worth
noting
that
rules
always
evaluate
prior
to
the
script
block,
so
we're
familiar
now
with
the
script
block
and
before
script
and
after
script,
but
these
rules
will
always
evaluate
prior
to
the
script
block.
If
statements
in
the
rules
block
can
reference
variables.
A
A
So
in
this
example,
we
have
here
every
rule,
that's
evaluating
the
CI
pipeline
source
and
we're
saying
that
if
it
matches
web,
the
job
will
be
created
in
my
pipeline
and
just
for
your
information,
it
would
match
web.
If
someone
clicked
the
Run
pipeline
button
in
the
UI
gitlab.
A
A
Then
next
to
that
we
have
our
operators
so
equals.
Then
we've
got
not
equals.
The
two
with
the
tilde's
are
regex,
so
not
equals
and
equals
to
whatever
regex
pattern.
You've
defined
and
then
the
double
Ampersand
is
to
join
operators
together
and
the
pipe
symbols
are
just
oars
so
either
or.
A
A
A
A
It's
also
good
to
know
how
to
make
a
job
in
your
pipeline
and
a
manual
step,
so
this
is
done
with
when
manual
and
in
this
example,
the
only
time
that
the
deploy
job
will
actually
execute
is
when
someone
comes
to
the
UI
and
actually
clicks
the
play
button.
As
you
can
see
here,
that's
because
this,
when
manual
rule
has
been
placed
in
so
they
actually
have
to
come
to
the
UI
and
click
the
play
button,
and
that
Playbook
will
only
be
visible
to
those
people
who
actually
have
permissions
to
run
it.
A
Another
example
is
where
we
use
multiple
rules
together,
in
this
case
our
rules,
reference
CI
pipeline
source,
which
is
one
of
our
predefined
variables,
and
it
actually
has
a
very
long
list
of
things
that
can
create
a
pipeline,
but
in
this
case
we
have
two
rules
that
state.
If
the
pipeline
Source
was
either
a
merge
request
event
or
if
it
was
scheduled,
then
it
should
run
so
this
is
where
we
can
use
multiple
rules.
You
see
that
we
do
that
by
using
these.
If.
A
So
this
job
will
be
created
when
the
pipeline
is
merged
to
master.
So
that's
when
it's
created
and
it
will
begin
in
three
hours
because
it's
delayed
and
it
won't
start
then
for
three
hours,
so
you
might
be
asking
well
three
hours
from
what
and
but
the
answer
is
that,
basically,
the
timer
of
a
delayed
job
starts
immediately
after
the
previous
stage
has
completed
so
three
hours
after
the
previous
stage.
It
is
complete.
This
guy
here
will
kick
off.
A
So
if
we
look
at
this
Pipeline
and
when
it
will
execute-
and
it
will
be
created
in
any
pipeline
when
the
pipeline
sources
not
merge,
request,
event
or
schedule,
as
you
can
see
here,
so
merge
across
event,
never
schedule
never
and
then
they
went
on
success.
Keyword
tells
the
job
to
execute
assuming
the
previous
job
success.
A
A
A
So
here
are
some
more
keywords
that
rules
can
be
evaluated
against,
and
in
this
case
we
have
if
changes
and
exists
changes
only
creates
the
job
of
a
file
in
one
of
the
specified
paths
is
changed
in
your
current.
Commit
exists
only
creates
the
job
based
on
the
existence
of
some
particular
file,
and
this
is
also
an
example
of
rules,
evaluation
on
a
custom
variable
versus
the
predefined
environment
variables
that
we've
already
seen.
A
We
don't
need
to
go
too
deep
onto
this,
but
it's
just
to
show
you
the
variables
processing
order
and
it's
a
good
slide
to
keep
for
future
reference.
If
you
ever
come
to
the
point
where
you
need
to
check
it
out,
and
it
just
basically
shows
the
order
of
Precedence
for
variable
processing
from
highest
to
lowest.
A
A
A
A
So
before
I
commit
anything,
you
can
see
that
it's
time
now
to
add
some
rules.
So
let's
start
with
a
basic
one
on
our
unit
test
job.
So
let's
go
up
here.
This
is
our
units
test
job.
Here,
let's
say
we
only
care
about
this
job
running
if
it
is
being
merged
into
main.
To
do
this
add
the
rule
definition
to
find
below
to
the
end
of
the
unit
test
job.
So
I'm
going
to
say
this
rule
I'm
going
to
put
it
right
at
the
end
of
this
job.
A
A
So
we
haven't
committed
anything
yet
and
we've
just
added
exit
one
to
the
script
of
our
code
quality
job.
A
A
A
Okay,
so
let's
go
ahead
and
commit
changes,
use
left
hand
menu
to
go
back
to
build
and
Pipelines,
so
I'm
going
to
go
in
here,
build
and
Pipelines,
and
you
can
see
we're
going
to
click.
The
hyperlink
for
the
most
recently
kicked
off
job
and
mine.
Is
this
one
here
you
can
see
it's
still
pending
some
available
Runners.
To
do
anything.
This
could
take
a
while
in
the
pipeline
view
as
the
jobs
run.
We
want
to
click
into
each
of
them
and
see
how
our
added
rules
and
low
failure
have
changed
the
output.
A
So
we
should
see
that
the
code
quality
job
fails
with
a
warning
so
on
this
code,
quality
job
I
expect
to
have
the
Amber
exclamation
mark.
You
might
remember:
I
showed
that
in
one
of
the
slides
to
just
demonstrate
how
they
look
when
they
failed,
but
we
should
also,
most
importantly,
see
that
the
pipelines
will
succeed.
So,
even
though
the
code
quality
job
fails
because
we
added
in
that
exit,
one
line
this
guy
here,
so
we've
purposely
made
a
fail.
We
still
want
to
see
the
pipeline
complete.
A
And
as
it
says
here
later,
we'll
add
more
stages
to
the
pipeline
as
well,
so
that
you
can
see,
even
though
the
job
fails.
The
pipeline
continues
to
run
and
note
that
if
you
use
the
completed
rules
and
those
failure
to
Target
Branch
for
the
rule
will
also
change
so
we're
just
going
to
leave
this
run
for
a
little
while
I
think
it's
probably
a
good
time
for
us
to
take
a
coffee
break
whatever
we
need
to
do.
I'll
just
move
us
on
here
and
yeah.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Let's
go
back
to
our
pretend
scenario:
the
exact
team
now
wants
to
make
sure
that
you're,
taking
full
advantage
of
all
of
the
gitlab
features
like
security
scanning
and
artifacts
and
they've
asked
if
you
can
demo
this
in
a
pipeline
in
the
next
stand
up.
A
A
A
A
A
It's
worth
pointing
out
people,
you
know,
think
there's
a
lot
under
the
hood,
with
templates,
but
they're,
really
not
magical
and
or
mysterious
at
all,
and
once
you
took
take
a
look
inside
one
which
we
will
do
in
a
minute.
You'll
see
that
they're
all
just
gitlab
cicd
files,
all
the
Syntax
for
the
CI
stages
and
jobs,
they'll
still
apply
and
thus
you'll
be
able
to
clearly
understand
the
jobs
that
you're
adding
to
your
pipeline.
By
using
these
templates.
A
There's
a
good
link
actually
that
I'm
going
to
share
into
the
chat
for
you
all
to
take
a
look
at
later
on.
This
is
a
link
to
all
of
the
templates
that
come
ship
with
gitlab
so
again,
another
another
good
resource
to
take
a
look
at.
A
To
look
at
include
statements,
you've
seen
there
that
that's
what
we
use
actually
include
the
templates,
so
we
had
include
template
this
guy
here,
but
there's
actually,
four
different
types
of
include
statements
and
you've
got
include
template,
as
I
said,
which
we
use
for
the
templates
that
are
on
offer
from
gitlab
engineering
if
that
include
local
file
and
remote
as
well,
which
are
all
ways
that
you
can
share
within
subgroups
within
your
own
org.
So
if
repos
are
Public
public,
you
can
actually
publish
and
consume
templates
from
the
community
outside
your
organization
as
well.
A
A
Remember
the
predefined
variables
that
we
discussed
earlier.
We
can
see
in
the
SAS
template
exactly
how
they're
defined
so
there's
some
of
the
predefined
variables
that
we
were
looking
at
earlier
on
and
you
can
see
their
description
and
exactly
what
they
do.
Then,
if
you
open
it
up
and
take
a
look
at
them,
you'll
see
it
all.
There.
A
A
So
for
to
talk
about
artifacts
in
gitlab,
you
can
get
to
the
artifacts
from
a
variety
of
places.
In
the
UI
itself,
you
can
download
any
of
the
artifacts
for
a
particular
Pipeline
on
the
actual
pipeline
job
and
or
for
a
specific
job
on
the
jobs
page
or
even
the
job.
Details
page
for
a
specific
job
and
they'll
always
get
downloaded
as
a
zip
file.
So
you'll
remember
this.
This
is
the
same
screen.
A
The
jobs
Details
page
also
gives
you
the
option
to
browse
the
artifacts
saved
so
that
you
can
see
all
of
the
directories
and
files
that
have
been
saved
for
that
job
instead
of
downloading
the
zip
file,
so
you
can
just
go
in
there
and
and
look
at
them
directly
and
artifacts
are
also
available
directly
via
the
API
for
scripted
operations
and
we've
included
documentation
links
in
the
references
that
you
can
check
out
if
you're
more
interested
in
that
topic,.
A
So
in
our
simple
pipeline
for
build
and
unit
tests,
and
we've
already
used
the
artifacts
keyword
to
store
the
this
directory
that
contains
the
results
of
the
build,
and
we
have
set
the
artifact
to
expire
in
an
hour,
but
even
after
an
artifact
expires,
it
will
not
be
deleted
until
a
newer
artifact
becomes
available,
so
we'll
be
deleted
after
the
next
build
run.
One
hour
after
this
artifact
was
created.
A
There's
one
other
thing
to
be
aware
of
is
that
you
must
have
the
appropriate
permissions
as
well
to
be
able
to
view
and
download
these
artifacts
for
public
projects.
Any
user
with
guest
permissions
are
greater,
can
actually
View
and
download
them,
but
for
private
projects
you
need
report
or
permissions
are
greater.
A
First,
we
need
to
get
back
to
editing
our
pipeline
from
last
track,
so
make
sure
you're
still
in
the
cicd
adoption
Workshop
project,
which
we
are
and
left
hand
menu
go
to
build
pipeline
editor
build
pipeline
editor
so
that
we
can
edit
our
pipeline.yaml
file
the
changes
that
we
want
to
make
so
under
where
we
Define
the
image
for
our
pipeline,
which
is
here,
you
can
see
image,
node
17,
we
will
add
the
below
code
to
include
the
SAS
template.
So
this
is
the
whole
include
template
section
that
we
just
mentioned
in
our
slides.
A
Now
this
is
a
this
is
a
nice
thing
to
know
so
to
take
a
look
at
the
template
that
we
just
added,
so
the
template
we
just
added
obviously
was
our
SAS
one
look
near
the
top
of
the
edit
page
where
you
can
select
the
branch
and
so
up
here.
You've
got
your
branch
and
to
the
left
of
that
this
icon
here,
if
you
click
on
that,
it's
going
to
show
any
templates,
you've
included.
A
So
even
if
I
had
three
or
four
listed
here,
they'll
pop
up,
so
that's
where
you
can
have
a
look
at
them.
If
you
want
to
actually
go
and
take
a
look
at
this,
you
can
click
on
it
here.
That's
that's
exactly
what
we
were
saying
when
I
mentioned
that
there's
nothing
mysterious
going
on
here
that
it's,
you
can
jump
straight
in
and
see
exactly
what's
happening
under
the
hood
for
these
SAS
Gunners.
So
you
can
see,
there's
your
variables
and
the
excluded
analyzers
things
that
we
mentioned
already.
A
It's
all
in
here,
so
feel
free.
If
you
ever
add
templates
like
that,
you
can
click
on.
As
I
said
this
icon
up
here.
Beside
your
your
branch
and
you
can
jump
out
into
the
templates,
so
that's
just
that
section.
We
wanted
to
show
you
how
to
do
that.
A
You
can
also
view
merge,
yaml
to
see
the
output
and
that's
okay.
For
now.
We
don't
need
to
do
that.
So
what
we're
going
to
do
is
go
ahead
and
commit
the
changes
that
we've
made.
So
we've
included
this
template
it's
time
to
commit
these
changes.
A
And
then
we're
going
to
go
back
to
our
pipeline
section
I
understand
that
a
lot
of
people
are
still
experiencing
delays
with
their
pipelines.
I'm.
Sorry
about
that,
as
I
said,
you
do
have
access
to
the
workshop
for
four
days.
So
hopefully
that
will
offer
up
enough
time
for
you
to
jump
back
into
either
any
sections
I
haven't
completed
for
you
or
anything.
You
want
to
try
again,
which
you
should
have
it
for
four
days.
So
it
shouldn't
have
enough
time
for
you
to
get
back
in
and
do
it.
A
A
Now.
The
first
thing
that
we
want
to
do
is
add
a
new
stage
call
security
to
house
all
of
the
SAS
jobs,
so
I'm
just
going
to
paste
that
in
there.
So
this
is
a
stage
here,
writing
security
and
now
we're
going
to
create
a
new
SAS
job
that
will
overwrite
some
of
the
functionality
from
the
template
we
included.
So,
even
though
we
included
this
template,
we're
now
going
to
override
something,
but
so
the
blow
code
sets
up
a
new
job
and
has
it
run
as
soon
as
the
pipeline
begins.
A
And
before
we
commit
the
code,
we're
now
going
to
go
ahead
and
look
at
the
add
artifact
keyword
as
well.
So
let's
say
a
requirement
comes
in
that
we
want
to
store
the
results
of
the
build
app
job
in
an
artifacts.
We
already
have
this
build
app
job
running,
but
what
if
we
want
to
store
the
results
in
an
artifact?
So
let's
add
a
change
to
the
job,
to
do
just
that.
You
can
basically
copy
this
and
replace
the
build
that
job.
That's
already
there.
A
You
see
this
download
button
here,
that's
the
one
we
were
referring
to
so
once
my
build
app
job
completes,
it
will
generate
the
artifact
as
we
create
here.
If
you
remember,
we
changed
the
build
up
to
create
this
artifact.
If
you
click
on
this,
you
can
see
now
it's
empty,
because
my
build
app
job
hasn't
actually
ran
when
it
does
run
and
when
yours
runs,
you
can
come
back
here
and
click
on
that
download
symbol
on
your
last
run
Pipeline
and
you
will
see
the
build,
app,
artifact
and
so
I'm.
A
Okay,
so
I'm,
conscious
of
the
time
folks
I
just
want
to
touch
on
the
last
couple
of
items
so
transferring
the
project
out-
and
this
is
totally
optional.
If
you
do
have
your
own
ultimate
instance
of
gitlab,
you
can
transfer
out
to
project
and
that
we've
worked
on
today,
so
that
the
whole
project
that
existed
in
that
training
environment,
you
can
transfer
it
out
to
do
that.
The
steps
are
in
the
the
issue
list,
as
I
showed
you
and
number
five
is
transfer
project.
A
It
will
walk
you
through
step
by
step,
how
to
take
a
copy
of
everything
and
move
it
out
into
your
own
environment.
It's
worth
noting
that
if
you
do
that,
but
you
don't
have
an
ultimate
gitlab
license,
you
are
going
to
lose
some
functionality
and
which
will
obviously
impact
you
know
some
of
the
stuff
we've
shown
you
today,
but
as
I
said,
you
have
that
training
environment
for
four
days
and
it
will
quieten
down
which
will
mean
that
you'll
be
able
to
see
those
pipelines
happen
in
front
of
you.
A
You
can
watch
the
progress
of
the
jobs
completing
so
please
take
the
time
to
go
back
and
explore
through
the
steps
again
and
if
anyone
does
have
any
issues
and
you
can
reach
out
to
us
and
that
is
it
and
I'm
conscious
not
to
run
over
too
long.
I
will
keep
the
meeting
open
for
a
couple
of
minutes
afterwards.
If
anyone
does
have
any
specific
questions,
put
them
in
the
Q.
A
and
I
can
offer
you
my
email
address
and
we
can
follow
up
after
this,
and
we
can
even
schedule
a
session
if
required.
A
So
I
hope
you
all
got
some
value
from
today
and
I
know
we
covered
a
lot.
We
had
to
do
a
a
bit
of
a
pace
and
we
experienced
some
issues,
but
hopefully
you
you've
still
seen
how
rich
the
the
feature
set
is
and
the
functionality
that's
available
to
you.