►
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
A
A
A
A
So
welcome
today
to
everyone's
to
everyone
today
for
this
session,
we're
going
to
be
covering
CI
using
gitlab
in
today's
Workshop
just
want
to
cover
some
housekeeping
items
first,
so
today
you're
going
to
be
provisioned
with
a
gitlab
ultimate
group
on
gitlab.com,
and
that
means
that
you're
going
to
need
to
have
your
gitlab.com
username,
registered
and
ready
for
this
session.
A
So
if
you
haven't
actually
got
an
account
on
gitlab.com,
please
go
there
now
and
create
one
and
you're
going
to
need
it
for
this
Workshop.
You
can
see
the
link
up
on
the
screen,
so
gitlab.com
forward,
slash
users
forward.
Slash
sign,
underscore
up
you're,
going
to
have
access
to
the
training
environment
that
we
provisioned
today
for
the
next
four
days,
which
would
be
really
good
you'll,
be
able
to
revisit
the
content
that
we
deliver
here
today
and
also
generally
get
a
feel
for
one
of
gitlab.com
ultimate
account
feels
like
an
explored
feature
set.
A
One
final
thing
to
note
is
that
today's
session
is
recorded
and
the
deck
along
with
the
recording
will
be
sent
out
to
you
in
the
next
couple
of
days.
A
A
Sorry
I
just
have
someone
saying
that
they
can't
hear
me:
I
just
want
to
do
a
quick
audio
check
and
make
sure
everyone
can
hear
me
and
that
it's
just
an
issue
with
that
participant
yeah
you've
got
some
okay,
brilliant!
Thank
you.
Everyone,
good
stuff,
so
after
today's
session
feel
free
to
connect
with
me
whether
it's
on
LinkedIn
or
even
on
gitlab.com.
You
can
take
a
look
at
some
of
my
contributions
to
the
rest
of
the
community,
so
our
agenda
for
the
workshop
today
we're
going
to
initially
go
to
our
lab
setup.
A
We're
going
to
provision
your
training
environments
on
gitlab.com,
then
we're
going
to
go
through
the
setup
of
a
simple
pipeline,
then
we'll
look
at
execution
order
and
directed
acyclical
graphs
and
we're
going
to
cover
some
rules
and
failures
and
then
move
on
to
SAS
and
artifacts.
A
A
Great
so,
let's
get
started
so
for
today's
session
we
have
a
fictional
new
startup
that
we're
all
members
of
that's
creating
a
public
leaderboard
for
the
hit
new
racing
game,
Tanuki
racing.
So
let's
pretend
that
your
company
has
recently
swapped
over
to
using
gitlab
for
cicd
a
new
Fantastic
learning
about
all
of
the
different
pipeline
capabilities.
A
A
Again,
I'm
going
to
be
pasting,
a
number
of
links
into
the
chat,
so
I'll
just
ask
that
if
anyone
does
have
questions
fire
them
into
the
Q,
a
they'll
get
answered
the
same
way.
It
just
keeps
the
chat
clear
for
these
links,
so
we're
going
to
go
to
gitlabdemo.com
and
I've
pasted
the
invitation
code
into
the
chat
as
well.
A
A
.Com
username
I
mentioned
previously
that
that's
what
we're
going
to
need
for
decision
and
I'm
just
going
to
show
you
now
how
to
grab
it.
So
if
you
go
to
gitlab.com
and
up
the
top
right
hand,
corner
you'll
see
your
icon,
which
is
your
profile
image
and
a
little
arrow
beside
it.
If
you
click
that
you're
going
to
get
this
drop
down
here
that
you
see
and
what
we
need
is
your
username
without
the
ad
symbol.
A
So
you
can
see
in
this
example,
my
username
is
at
J
conrad2
and
all
I
need
is
the
J
Conrad
2
part.
So
again,
you're
going
to
go
to
gitlab.com
you're,
going
to
click
on
your
profile
picture.
It's
going
to
present
a
drop
down,
and
just
beneath
your
name,
it's
the
J,
Conrad
2
part.
You
need
just
your
username
without
the
ad
symbol.
A
So
we're
going
to
input
the
username
that
we
just
collected
into
this
field.
This
is
gitlab.com
username
and
you're,
going
to
click
on
provision,
training,
environment,
again,
I'm
just
going
to
ask
that
everyone
uses
the
Q
a
section
for
our
questions
today
and
not
the
chat
box,
so
Simon
John,
Eduardo
I
can
see
a
couple
of
comments
coming
through
just
to
keep
that
chat,
box
clean
and
as
well
putting
them
in
the
Q
a
will
ensure
that
your
questions
get
answered
throughout
the
session.
So
please
put
them
in
the
Q.
A
A
This
is
the
screen
that
you
should
all
end
up
with.
This
means
that
everything
was
successful
and
your
training
environment
is
provisioned
and
right
here,
you're
going
to
get
your
link
to
the
provision
training
environment.
This
gitlab
URL
I
would
recommend
that
you
copy
it
and
put
it
somewhere
safe
for
the
session,
because
you'll
be
returning
here
after
you
can
also
click
on
the
my
group
button
and
that
will
bring
you
to
this
environment.
A
So
now
I'm
going
to
go
through
those
steps
live
so
that
you
can
see
exactly
what
to
do.
Here's
gitlabdemo.com
I'm,
going
to
click
on
the
blue
redeem
invitation
code
button
I'm,
going
to
grab
my
invitation
code
like
so
I'm,
going
to
click
on
provision,
training,
environment,
I'm,
going
to
put
in
my
gitlab.com
username.
So
without
the
ad
symbol,
it's
j
Conrad,
two
and
I'm
going
to
click
on
provision,
training
environment.
A
So,
as
I
said,
this
is
a
page
that
we
should
all
see.
Here's
my
URL
to
the
training
environment
and
you
can
also
click
on
my
group
to
get
there
if
at
any
stage,
you've
copied
and
pasted
this
and
you
misplaced
it.
During
the
session-
and
you
need
to
get
back
here-
you
can
just
go
back
to
get
that
demo.com
put
in
the
invitation
code
and
your
username
again
and
it'll
bring
you
right
back
here,
just
another
way
to
get
back
here.
A
So
this
is
what
you
should
all
see.
This
is
your
test
group
in
gitlab.com
up
here,
you're,
going
to
see
the
name,
it'll
say
my
test
group
and
then
a
string.
So
your
string
here
is
going
to
be
different
to
mine,
but
I'd.
Ask
you
all
to
do
now
is
just
copy
and
paste
this
string
somewhere
safe.
It
will
make
a
future
step
far
easier
for
you,
so
in
your
trading
environment.
Just
go
up
the
top
and
copy
this
string
here
after
my
test
group
just
copy
and
paste
that
summer.
A
A
A
If
we
go
back
to
our
fictional
scenario
that
we
were
talking
about,
your
product
manager
has
given
you
your
first
task,
which
is
to
create
a
simple
pipeline
that
bills
and
tests
the
racing
application.
A
A
I'm
just
going
to
paste
that
link
in
here
and
go
to
it.
So
this
is
what
you
should
all
see.
This
is
going
to
be
our
source
project
for
today,
so
to
be
really
clear.
What
we're
doing
is
we're
using
this
as
our
source
project
and
we're
going
to
essentially
Fork
it
into
our
training
environment,
where
we
can
then
work
on
it
for
today's
session,
so
I've
copied
and
pasted
that
link
into
the
chat
box.
If
you
can
all
go
there
now.
A
A
A
All
of
your
other
options
can
stay
as
default.
So
to
be
clear,
we
went
to
our
CI
CD
adoption
Workshop
page.
We
clicked
on
Fork
we're
keeping
the
name
as
standard
in
here
you're
telling
it
where
to
Fork
the
project
into,
and
you
want
to
paste
in
this
string
which
tells
it
to
Fork
it
into
your
provision.
Training,
environment,
keep
everything
else
as
standard
and
click
on
form
project.
A
Great,
so
you
can
see
here,
forked
from
gitlab
learn
Labs
into
your
into
your
correct
Group,
which
you
can
actually
see
up
here.
So
what
I'll
do
here
is
I'll
just
refresh
this
group
over
here,
so
that
you
can
see
it
great.
A
A
So
you're
going
to
settings
in
general
and
then
down
to
Advanced,
where
you
want
to
expand
I'll,
be
showing
all
this
in
the
slides
and
in
a
minute.
So
you
do
have
a
bit
of
time
to
complete
these
steps,
but
you're
going
to
settings
General
you're
going
to
expand
out
advance
and
scroll
the
whole
way
down.
The
second
last
option
here
is
the
one
that
we
want
to
use,
which
is
remove
Fork
relationship,
so
I'm
going
to
go
ahead
and
click
on
this
right
now.
A
A
Once
you
get
this
far,
you
can
just
click
back
up
to
your
project
overview
and
leave
it
here,
I'm
going
to
cover
that
again
now
in
the
slides
just
to
make
sure
everyone
got
it.
So
we
went
to
our
source
project.
That's
the
link
in
the
chat
he
clicked
on
Fork
up
on
the
top
right
hand
corner
you
paste
it
in
the
string
from
your
provision.
Training
environment
here
kept
everything
else.
As
default,
you
clicked
Fork
project.
A
So
I
do
hope
everyone
is
up
to
speed
and
that
we're
all
good
on
that
front
and
I
do
see
an
anonymous
attendee
asking
the
question
about
what
does
fork
mean.
So
forking
is
process
where
you
can
essentially
create
a
copy
of
a
source
project
for
yourself
and
when
you
in
particular,
when
you
remove
that
fork
relationship,
and
you
begin
working
on
that
project
yourself.
It's
totally
in
your
own
environment.
Any
changes
you
make
are
not
reflected
in
the
source
project,
which
is
what
we
did
today.
A
What
I
want
to
do
now
is
copy
this
link
here
into
the
chat
box,
for
you
all
to
use.
This
is
the
next
one
you're
going
to
open
up
and
I
think
it's.
The
last
link
I'll
be
sharing
with
you
today.
So
if
you
can
just
go
ahead
and
open
up
that
link
that
I've
pasted
in
the
chat,
it
should
bring
it
to
this
page
here.
A
What
I
would
recommend
is,
if
you
have
two
screens,
it's
great
to
have
your
provision,
training
environment,
on
one
side
and
on
the
other
side,
if
you
can
have
your
instruction
set,
which
is
the
link
that
I
just
copied
and
pasted
in
that
would
be
really
really
good,
because
it
means
that
throughout
the
session,
then
you
can
jump
between
the
two.
A
Okay,
there's
a
number
of
people
saying
that
they
don't
see
the
remove
Fork
relationship.
So
if
you
have
forked
the
source
project
into
your
training
group,
you
go
to
settings
General
when
you're
in
general.
You
want
to
scroll
down
to
Advanced,
expand
this
out
now.
Mine
won't
be
here
anymore,
because
I
just
did
it,
but
down
here.
Second
last
you're
going
to
see
remove
Fork
relationship.
B
A
So,
as
I
was
saying
it's
great,
if
you
have
your
provision,
training,
environment
to
one
side
and
your
instruction
set
on
the
other,
these
are
all
the
steps
that
we're
going
to
complete
today.
So
we're
going
to
start
off
with
our
simple
pipeline,
then
we
work
out
execution
order,
dikes
rules
of
failures,
SAS
and
then
the
final
ones
are
all
optional
and
so
keep
these
open
side
by
side.
For
today
and
we'll
start
working
through
the
workshop.
B
A
A
Firstly,
what
you're,
seeing
here
in
the
columns
are
the
stages,
so
you
can
see,
we've
got
a
build
stage,
a
test
stage
and
a
deploy
stage
reflected
down
here
in
the
pipeline
diagram
beneath
them.
You
can
see
the
jobs
that
are
associated
with
each
stage,
so,
for
example,
our
build
stage
has
a
build
job
and
our
test
stage
has
two
test
jobs.
A
One
thing
to
know
about
gitlab
pipelines
is
that
by
default,
all
jobs
in
a
stage
must
complete
successfully
before
proceeding
to
the
next
stage.
That's
to
say
that
in
its
default
consider
configuration
using
this
example,
this
build
stage
or
this
build
job
in
the
build
stage,
would
need
to
complete
successfully
before
any
of
the
test
jobs
can
begin.
A
A
So
whenever
you're
writing
jobs,
you'll
always
have
this
script
keyword
defined
without
it.
The
job
doesn't
do
anything
and
doesn't
exist.
Every
job
needs
this
script
statement
included
in
addition
to
script.
You
do
also
have
the
option
to
include
before
script,
and
you
don't
see
it
here,
but
there's
another
one
as
well,
which
is
after
script,
so
before
script
runs
before
the
script
statement
put
in
the
same
shell
as
the
script
saved.
A
Its
main
purpose
is
to
run
steps
that
are
necessary
in
order
for
the
script
statement
to
execute
properly.
A
good
example
of
this
would
be
the
before
script
statement,
installing
the
AWS
CLI
and
then
the
script
statement
actually
executing
some
AWS
CLI
commands
like
the
before
script.
As
I
said,
there
is
an
after
script
statement
which
can
rest
down
here
in
a
different
way.
The
after
script
runs
in
a
separate
shell,
so
a
good
example
of
an
after
script
would
be
cleanup.
A
For
example,
you
can
also
evaluate
the
exit
code
of
script
in
after
script
and
have
additional
job
behaviors,
depending
on
the
result.
So
in
your
after
script
that
you
might
have
down
here,
you
could
assess
well.
How
did
our
our
script
statement
go
and
based
on
the
output
of
that
do
something
different
afterwards?
A
When
you
register
Runner,
you
can
also
add
tags
to
it
and
when
a
cicd
job
runs,
it
knows
which
Runner
to
use
by
looking
at
these
assigned
tags
tags
are
the
only
way
to
filter
the
list
of
available
Runners
for
a
particular
job.
So,
for
example,
if
your
Runner
has
the
Ruby
tag
which
this
one
here
does
you
can
see
job
tags
Ruby,
you
would
add
it
to
your
project.
A
Okay,
so
we're
going
to
take
a
look
at
some
of
the
Hands-On
steps.
Now
we've
got
our
instructions
open
to
one
side
and
our
provision:
training
environment,
open
on
the
other
side,
I'll
paste
the
link
into
the
instructions
again
into
the
chat
for
everyone,
just
so
that
you
have
them
there.
A
This
is
linked,
as
I
said,
that
includes
all
of
the
instructions
for
today
and
today,
we're
gonna
or
for
now
we're
just
gonna
open
up
the
first
one,
which
is
number
one
simple
pipeline,
you'll,
see
in
it
that
it
covers
some
of
the
work
we've
already
walked
through
in
terms
of
forking
the
project
into
your
training
environment.
So
we
can
jump
ahead
to
step
two.
B
A
So
it
says
first,
click
on
project
overview
in
the
top
left
of
the
screen,
which
is
up
here.
This
guy
here
brings
us
to
the
project
overview
and
it
says
that,
because
we
have
our
project
imported,
we're
going
to
go
ahead
and
take
a
look
at
the
gitlab
CI
yaml
file.
Now
I
have
a
different
way
that
I
like
to
do
this
and
I'd
like
you
guys
to
do
it
as
well.
So,
instead
of
just
clicking
on
the
gitlab
CI
yaml
file
here
that
exists
in
the
root
of
the
project.
A
So
again,
you're
going
to
go
to
build
and
pipeline
editor,
so
notice
that
we
have
a
simple
pipeline
already
defined.
We
have
our
two
stages
up
here,
defined
at
the
start,
stages
build
and
test,
and
we
have
two
jobs
as
well.
So
we
have
our
build
up
job,
which
is
down
here
this
guy
here
build
up,
and
we
also
have
a
before
script
and
an
after
or
sorry
a
before
script
and
script.
A
As
part
of
this
job,
if
you
look
down
here,
then
we
have
a
unit
test
job
that
currently
has
a
before
script
and
a
script
as
well
and
in
the
unit
test
job.
We
want
to
use
the
after
script
keyword
to
Echo
out
that
the
build
has
completed
so
again,
you're
going
to
go
to
the
left
hand,
side,
build
pipeline,
editor,
open
up
your
pipeline
here
and
we're
going
to
add
the
after
script
job
or
the
after
script
statement.
A
A
A
A
A
Here
you
know,
if
you
remember
the
job
that
we
edited
was
the
unit
test
job
and
what
we
did
was
we
added
an
after
skirt
to
Echo
out
that
the
build
app
job
has
run,
which
basically
says
once
the
before
script
and
script
has
run
for
the
unit
test
job.
It's
going
to
run
the
after
script,
to
Echo
out
a
confirmation
message
that
it
runs
successfully.
A
If
there's
a
moment
and
see
if
we
can
watch
it
live,
there's
a
chance
it
might
take
too
long,
but
to
shot.
A
Through
our
build
up,
job
is
still
running
okay,
so
we
can
come
back
here
in
a
in
a
moment
when
we
get
to
the
next
step,
we'll
actually
come
back
and
confirm
that
we
can
see
this
haven't
been
echoed
out,
but
for
now
we
can
we
can
drive
on.
We
don't
need
to
sit
here
and
watch
it.
A
So
now
we
have
our
simple
pipeline
set
up:
we've
added
our
after
script
to
our
unit
test
job.
So
let's
now
talk
a
bit
more
sorry
about
a
bit
more
of
an
advanced
scenario,
with
job
execution
order
and
as
well
directed
acyclic
graphs,
which
for
easiness
sake,
I'm
going
to
call
dags
from
now
on
and
then
we'll
get
into
another
Hands-On
example
in
our
lab
environment.
A
A
So
what
if
we
wanted
to
adjust
this
execution
order
in
a
pipeline
to
increase
its
efficiency?
The
pipeline
graph
shows
us
the
pipeline
stages
and
jobs,
which
you
can
see
here
and
in
terms
of
execution
order.
In
this
scenario,
let's
imagine
that
a
QA
team
has
added
the
code
quality
job
to
the
test
stage.
You
can
see
it
here
so
above
our
unit
test
job.
We
now
have
this
code.
A
So
how
do
we
do
that?
How
do
we
adjust
the
job
execution
order
for
this
code?
Quality
job?
We're
going
to
look
at
that
by
using
the
needs
keyword,
but
first,
just
as
we
speak
about
code
quality,
it
is
worth
mentioning
that
gitlab
has
a
code
quality
template
that
can
also
be
used
and
will
actually
cover
the
use
of
templates
as
well
in
a
at
a
later
section
today.
A
This
keyword
allows
us
to
specify
which
jobs
need
to
be
run
before
this
job
can
start
and
by
leaving
the
value
empty
over
here,
we're
asserting
that
this
code
quality
job
can
be
run
as
soon
as
the
pipeline
begins.
It
needs
nothing
else
to
complete
before
it
in
step.
Two
of
our
Hands-On
tasks,
we're
going
to
work
with
this
needs
keyword
and
you'll,
get
to
see
it
in
action.
A
A
The
test
job
for
iOS
should
not
have
to
wait
for
the
Android
build
jobs
to
complete,
as
they
only
need
the
iOS
build
jobs
to
have
completed
for
it
to
drive
on
successfully
so
I
hope.
That's
clear
about
how
using
multiple
needs
can
generate
this
directed
acyclic
graph.
Here
it's
worth
noting
another
use
case
that
creates
a
stageless
pipeline.
Essentially,
you
can
build
a
stateless
pipeline
where
you
declare
needs
on
every
single
job.
A
In
general,
we
don't
tend
to
recommend
it
as
it's
much
clearer
and
easier
to
follow
a
jobs
by
category
type
setup,
but
it
is
worth
noting
that
it
can
make
your
pipeline
more
efficient
if
you're,
in
a
position
where
you
could
express
the
whole
pipeline.
A
hundred
percent
by
only
using
this
needs
keyword,
so
it
has
its
uses,
but
it's
not
something
we
generally
recommend
using
okay.
So
let's
go
back
to
our
Hands-On
steps.
Hopefully
our
last
pipeline
has
finished
which
it
has
super
stuff.
So,
let's
first
of
all,
go
back
in
here.
A
I
want
to
show
you
where
this
after
script,
that
we
added
to
the
unit
test
job
has
done
its
business.
It's
going
to
click
in
here
to
access
a
pipeline.
That's
right
and
you
can
either
click
on
the
past
or
you
can
click
on
this
hashtag
number
here.
So
we're
going
this
way
so
I
want
to
click
into
my
unit
test
job,
just
to
show
you
what
it's
done
and
if
I
scroll
down
you
can
see
this,
so
it
started
running
the
after
script
that
we
added
to
running
it
and
it
echoed
out
build
app.
A
Job
has
run.
That
was
the
after
script.
We
added
in
the
last
step.
I
just
wanted
to
show
you
that
before
we
proceed
cool,
so
we're
going
to
go
back
to
our
list
of
instructions.
If
you're
still
on
this
page,
you
can
just
click
issues
up
here
and
we're
going
into
number
two,
which
is
execution
order
and
Dags
I'll
actually
just
paste
that
into
the
chat
for
you
to
bring
you
there
quicker.
If
it
helps
and
on
this
left
hand
side,
we
will
be
going
back
into
our
pipeline
editor
again.
A
Okay,
so
basically
this
just
saying
to
go
back
there
and
we're
going
to
explore
what
we
can
do
with
the
needs
keyword
so
to
edit
the
pipeline.
As
I
said,
you're
going
to
go
to
the
left
hand,
side,
build
and
then
pipeline
editor,
and
what
we're
going
to
do,
then
is
you
can
see.
We
only
have
the
unit
test
job
running
during
the
test
stage
and
we're
going
to
add
the
code
quality
job
that
we
discussed
in
those
previous
slides
below
the
unit
test
job.
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.
So
we're
going
to
add
the
following
line
to
the
end
of
the
unit
test
code
block,
which
is
our
empty
needs,
keyword
and
we're
going
to
add
it
to
the
bottom
of
the
unit
test.
Job
just
going
to
create
some
space
here
again
make
sure
your
indentation
is
good
and
I've
added
it
just
to
the
bottom
of
our
unit
test.
A
A
Okay,
so
we're
going
to
go
ahead
now
and
click
click
on
Commit
changes.
Again,
you
can
leave
the
commit
message.
Blank
send
it
to
main
branch
click
on
Commit
changes
at
the
left
hand
side.
We
want
to
see
this
in
action,
so
we're
going
to
go
to
build
and
Pipelines
you
can
see.
Mine
is
probably
pending
for
an
available
Runner
to
run
it.
A
Yours
is
probably
in
the
same
state.
It
will
start
shortly
I'm
sure
for
workshops
like
this.
We
use
a
shared
Runner
setup,
so
it
can
be
a
little
bit
slower
than
than
the
real
world,
but
it's
obviously
because
we're
all
using
training
environments
that
have
been
provisioned
and
so
we've
gone
ahead.
We've
committed
those
changes
you
can
see.
My
pipeline
is
now
running
here.
A
And
what
you
want
to
see
is
that
as
you
watch,
you
can
basically
see
the
two
jobs
running
parallel,
so
you
can
see
the
cold
quality
job
is
actually
finished
on
mine,
so
he
didn't
hang
around
for
this,
build
that
job
to
complete,
because
we've
defined
the
needs
keyword
as
empty.
He
just
went
off
and
started
by
himself.
Also.
A
A
A
A
B
A
We
can
create
one
so
we're
not
going
to
complete
a
fully
flushed
out
tag
for
this
Workshop.
As
it's
out
of
scope,
it's
going
to
be
a
really
simple
one,
just
to
demonstrate
what's
possible.
A
A
You
can
see
that
we're
going
to
add
them,
underneath
our
existing
code
quality
job
and
the
easiest
way
to
do
this
because
there's
so
many
of
them.
It's
just
copy
the
whole
block
so
up
here,
just
click
on
this
guy
there,
as
I
said
we're
going
to
paste
them
underneath
our
code
quality
job
scroll
down.
That's
our
build
app
job,
our
unit
test,
job,
a
cold
quality
job,
and
it's
down
here
that
it's
going
to
live
so
you're,
going
to
paste
them
all
in
there
and
you
can
see
there's
a
whole
bunch
of
them.
A
So
again,
if
you
now
click
on
the
visualize
tab,
which
is
something
different,
we
haven't
done
this
in
previous
steps,
but
if
you
do
click
on
the
visualize
tab,
you're
going
to
see
just
how
complex
many
stages
are.
So
let's
do
that
right
now,
it's
up
here.
It's
actually
very
handy
and
useful
if
you're
authoring
your
own
pipelines-
and
you
want
to
see
exactly
what's
happening
and
how
it's
going
to
happen
before
you
ever
commit
them.
It's
a
very
useful
feature
for
that.
A
So
click
on
visualize
above
the
pipeline,
editor
and
you'll,
see
now
all
the
relationships
between
them.
So
from
looking
at
this
I
mean
this
is
quite
a
simplistic
one,
but
we've
seen
some
that
are
incredibly
complex
and
they
allow
you
to
see
okay
well,
testy
needs
ability
to
complete
before
it
can
do
anything
like
deploy.
C
needs
test,
C
test
C
needs
build
C.
A
So
again,
this
is
a
very
simplistic
representation
of
a,
but
this
stuff
can
get
pretty
complicated
and
having
this
visualize
feature
here
allows
you
to
untangle
it
pretty
quickly:
Okay
cool,
so
we're
going
to
go
back
down
just
commit
those
changes.
Go
back
to
edit,
you
can
leave
the
commit
message
on
the
branch
and
just
click
on
Commit
changes.
A
A
What's
interesting!
Here
now
is
you'll
see
you
can
group
jobs
by
stage
which
obviously
puts
all
the
build
jobs
build
stage
the
test
jobs
test
stage,
the
deploy
jobs
in
the
deploy
stage,
or
you
can
group
them
by
dependencies,
which
is
an
interesting
example
of
it.
You
can
see
build
a
sorry
test
day
needs
build
a
deploy,
a
need
to
test
it
and
so
on.
If
you
toggle
this
guy
over,
it
actually
links
the
dependencies
so
that
you
can
see
them
the
whole
way
across
and
again.
A
A
Again,
we
don't
need
to
wait
for
it
to
complete
it's
just
to
show
you
the
example
that
you
can
see
these
dependencies
and
the
Dag
is
another
example
of
it.
If
we
go
across
up
the
top
from
pipeline
across
the
needs,
it's
another
visual
representation
of
the
needs
relationship
between
them
all
the
dependencies,
Okay
cool.
So
we
don't
need
to
wait
around
here.
For
this
to
finish,
we
can
drive
on
go
back
to
our
slide.
Deck
I
hope
everyone's
following
along
and
everything
is
going.
A
Okay
for
everyone
see
some
q
a
there
they're
all
being
answered
thanks
Morgan
for
your
help,
the
Q
a
section.
A
A
A
Innocent
in
the
Q,
a
you're
saying,
you're,
getting
an
error
that
the
CI
configuration
is
a
valid
deploy.
A
job
chosen
stage
does
not
exist.
Looks
like
you
missed
a
step
where
we
added
a
new
stage,
so
at
the
top
in
your
pipeline,
editor
make
sure
you
have
deploy
added.
A
Sorry,
if
I
I
don't
actually
have
any
way
of
sharing
my
ciml.
Unfortunately,
if
I
did
that
it
indentation
and
the
structure
of
it
would
all
go
terrible
in
Zoom
chat,
I'm,
afraid.
A
Let
us
know
that's
a
good
question:
is
there
anything
related
behind
the
color
transition
in
the
needs?
Panel?
I
actually
don't
know
the
answer
that
off
the
top
of
my
head
I,
don't
believe
so.
I
think
it's
just
when
they
get
very
complicated.
They
keep
the
same
color
flowing
true
so
that
you
can
easily
track
it.
A
Okay
cool,
so
hopefully
that's
a
long
enough
break
for
everyone
and
we
can
drive
on
now
we're
going
to
look
at
the
next
section
where
we're
going
to
talk
about
rules
and
failures.
A
A
A
So
sometimes
we
actually
want
to
allow
a
job
to
fail
and
for
it
to
be
flagged
as
failing,
but
not
stop
the
execution
of
the
rest
of
the
pipeline.
So
to
achieve
this,
we
can
use
the
allow
failure
keyword
on
a
job,
so
you
can
see
here
is
a
unit
test
job
run
in
the
test
stage.
They've
got
their
before
script
script
and
down
here,
they've
used
a
level
failure
and
set
the
value
to
true.
A
You'll
see
failed
jobs
in
your
pipeline
with
this
kind
of
Amber
exclamation
mark
in
the
circle.
Now
this
one
is
actually
a
manual
step.
Someone
is
going
to
press
play,
but
if
this
was
and
set
the
manual,
you
would
see
in
this
example
that
this
this
is
just
running.
This
job
is
not
waiting,
it
doesn't
care
the
test.
B
has
failed.
It's
just
driving
on,
because
yellow
failure
is
set
to
true.
A
We
also
know
that
the
default
behavior
of
a
job
is
to
stop
a
pipeline
if
it
fails,
because
the
keyword
allows
failure
defaults
to
false,
so
that
keyword,
we
discussed
in
the
last
Slide
the
allow
failure
that
guy
actually
defaults
to
false,
so
in
its
default
configuration
in
a
pipeline.
If
a
job
fails,
it
stops
the
execution
of
any
future
jobs
to
be
clear
about
when
a
job
is
included
in
a
pipeline.
A
A
A
So
what
exactly
can
rules
keyword
do
and
so
the
rules
keyword
can
actually
evaluate
a
list
of
conditions.
It
can
evaluate
conditions
based
on
a
selected
set
of
attributes
of
a
job
and
it
can
determine
if
the
job
is
created
or
not
the
pipeline.
So
in
this
example
here
you
can
see.
I
have
a
rule
that
is
evaluating
the
CI
pipeline
source
and,
if
it
matches
web,
the
job
will
be
created
in
my
pipeline
and
just
for
your
information
it
would
match
with.
If
someone
had
clicked
on
the
Run
pipeline
button
in
the
UI.
A
Again,
I'm
sure
you're
all
pretty
familiar
with
these
kind
of
rule
syntax,
but
it's
good
to
just
get
a
refresher
on
them.
This
is
a
nice
breakdown
of
all
those
rules,
syntax,
so
in
the
first
box
to
the
left,
you've
got
your
Clauses,
so
if
obviously
can
be
a
variable,
changes
can
be
if
a
file
has
changed
and
exists
can
be
if
a
file
actually
exists
or
not.
A
Next
to
that
we
have
our
operators,
so
you've
got
equals,
not
equals
the
two
with
the
tilde's
or
regex,
so
either
not
equals
or
equals
to
whatever
regular
expression
pattern
you've
defined,
then
the
double
double
Ampersand
is
to
join
operators
and
the
pipe
symbols
are
just
ores,
so
either
or
next
you've
got
job
attributes
which
are
when
allow
failure
and
start
in
a
start
in
is
essentially
delayed
execution.
So,
for
example,
start
in
five
minutes
and
when
is
quite
simply
when
the
job
should
run,
you've
got
always
never
success,
failure,
manual
or
delayed.
A
A
Okay,
so
when
is
the
job
not
created
in
a
pipeline?
Well,
when
none
of
the
rules
defined
for
the
job
evaluated
true
or
when
a
rule
does
evaluate
the
true,
but
has
a
clause
of
when
never
or
where
no
rules
are
defined
at
all,
but
whenever
Clause
is
specified,
that's
when
a
job
is
not
created
in
your
pipeline.
A
It's
good
to
know
how
to
make
a
job
in
your
pipeline
a
manual
step.
This
is
done
with
when
manual
and
in
this
example
the
only
time
that
the
deploy
job
here
will
execute
this
guy
over
to
the
right
hand,
side
is
when
someone
comes
into
the
UI
and
actually
clicks
on
the
play
button
on
this
job.
The
play
button
will
actually
only
be
visible
to
those
who
have
permissions
to
actually
run
it,
and
unless
you
haven't
defined,
who
can
run
it,
then
a
developer
can
run
it.
A
You
can
see
this
deploy
job
when
the
center
manual,
which
means
you
get
the
play
button
that
play
button,
is
only
visible
to
to
those
who
have
the
correct
permissions.
A
Another
example
is
where
we
use
multiple
rules
in
conjunction
with
each
other,
so
in
this
case
our
rules,
reference
CI
pipeline
source,
which
is
one
of
our
predefined
variables.
It
has
a
very
long
list
of
things
that
create
a
pipeline,
but
in
this
case
we
have
two
rules
that
stay.
If
the
pipeline
Source
was
either
a
merge
request
or
scheduled,
then
it
should
run
so
you
can
see.
This
is
an
example
of
using
multiple
rules
together.
A
It
also
has
start
in
defined
as
three
hours,
so
you
might
be
asking
well
three
hours
from
what
the
answer
is
from
our
documentation
that
the
timer
of
a
delayed
jobs
starts
immediately
after
the
previous
stage
has
completed.
So
whatever
stage
was
previous
to
this
one,
once
that's
completed,
the
timer
starts
for
this.
A
So
next
up
is
a
case
where
we
have
multiple
rules
and
the
when
keyword
in
play.
So
if
we
look
at
this
Pipeline
and
when
it
will
execute,
you
can
see
that
it'll
be
created
in
any
pipeline
when
the
pipeline
source
is
not
merge,
requests
or
schedule
here
we
go,
then
the
when
on
success
keyword
tells
us
that
the
job
is
to
execute
assuming
the
previous
job
success
when
on
success,
and
so
if
the
valuation
got
this
far,
we
know
that
none
of
the
previous
criteria
was
matched.
A
A
A
Okay,
so
here
are
some
more
keywords
that
rules
can
be
evaluated
against.
In
this
case,
we
have,
if
changes
and
exists,
so
changes
only
creates
a
job
if
a
file
in
one
of
the
specified
path
has
changed
in
your
current,
commit
exists
only
creates
the
job
based
on
the
existence
of
a
particular
file.
This
is
also
an
example
of
a
rules,
evaluation
and
a
custom
variable
versus
the
predefined
environment
variables,
so
they're
using
custom
variables
here.
A
Okay,
so
perhaps
you
want
to
understand
a
variable
processing
order,
here's
a
really
good
slide
for
a
future
reference
on
it.
We
won't
be
going
deep
on
it
right
now,
but
if
you
wanted
to
look
at
the
order
of
Precedence
for
variable
processing
from
highest
to
lowest,
this
is
it
here
again
we'll
share
the
deck
after
today's
sessions.
You'll
have
this
to
review
in
future.
A
Okay,
so
we've
got
our
next
step
now,
which
is
to
go
back
and
take
a
look
at
our
Step
tree,
which
addresses
rules
and
failures
or
we'll
take
a
look
at
our
existing
Pipeline
and
modify
it
to
show
how
useful
rules
and
allow
failure
can
be.
And
after
that,
we'll
take
our
coffee
break.
So
we
only
have
one
more
kind
of
manual
step
to
do
and
then
take
a
quick
break
for
some
coffee.
A
You
can
see
our
last
pipeline
here
ran
successfully.
This
was
the
one
where
we
added
a
ton
of
jobs
in
to
demo.
The
Dag
see
that
they
all
ran
successfully.
If
we
go
into
needs.
A
Cool
okay,
so
back
to
our
instructions,
we're
going
to
go
to
number
three,
which
is
rules
and
failures.
Again,
I'll
copy
this
into
the
chat
to
make
it
easy
for
you
to
get
back
there
up
the
top
left
hand
side
of
your
training
environment.
You
should
click
back
up
here,
just
to
bring
you
back
to
the
overview.
A
A
A
You
can
speak
okay,
it
also
tells
us
to
fix
the
stages,
because
we
added
in
a
deploy
stage
in
our
last
step.
We
no
longer
need
that
you
can
delete
that
out
of
there.
We
should
only
have
to
build
and
test
stage
and
now
I
believe
someone
at
some
stage
in
the
Q
a
asked
for
an
exact
copy
of
what
the
gitlab
CI
yaml
should
look
like
here
you
go,
you
can
just
copy
it
there
from
a
part
tree
so
to
ensure
that
we're
all
back
at
the
same
point.
A
A
A
A
A
A
A
So
you
can
see
I'm
allowing
failure,
so
we're
causing
a
failure
up
here,
but
we're
actually
allowing
it
so
for
your
yaml
for
the
code
quality
in
unit
test
job.
After
all,
the
changes
have
been
made.
You
can
just
copy
this
block
here
if
it's
easier
for
you.
So
if
you
copy
this
block
and
then
replace
your
code,
quality
job
and
your
unit
test,
job
you'll
make
sure
that
everything
is
perfect
for
the
next
step,
so
for
Next
Step.
What
we're
going
to
do
is
commit
these
changes
and
we're
going
to
go.
Look
at
them.
A
A
View,
which
is
this
view
here,
make
sure
you're
set
back
up
to
stages
of
the
top
check
into
each
of
them
to
see
how
our
rules
so
sorry
how
our
added
rules
and
low
failure
have
changed.
The
output
and
mine
aren't
running
yet
so
you're
not
really
going
to
see
anything.
A
But
the
idea
here
is
that
our
rules,
because
we
committed
to
main
you're,
going
to
see
that
the
rule
pass
and
as
well,
because
we
allowed
failure,
even
though
we
force
the
code
quality
job
to
fail
by
adding
the
exit
one
line
to
the
script
of
that
job,
it
will
fail,
but
it's
allowed
to
fail.
So
this
should
fail,
but
still
unit
tests
should
proceed.
A
This
is
probably
going
to
take
a
little
bit
of
time
to
run,
so
it
could
be
a
good
idea
for
us
to
take
or
a
coffee
break
now.
T
bio
break
whatever
you
need
and
we
will
come
back
so
I'll
set
the
timer
at
seven
minutes
so
about
12
minutes
fast,
we'll
all
come
back,
we'll
see
you
then.
A
A
A
A
A
A
A
A
A
A
A
And
that
you
got
your
caffeine
fix
or
water
fix,
whatever
you
needed,
I
just
want
to
just
pop
back
to
our
last
step
here.
To
show
you
that's
what
a
failed
job
that's
allowed
to
fail,
looks
like
you've
got
your
Amber
exclamation
mark,
see
it
actually
failed.
We
should
see
our
there.
You
go,
there's
your
exit
code,
one
that
we
actually
added
ourselves
to
force
it
to
fail.
A
I
just
want
to
show
that,
even
though
that
one
failed.
Let's
see
this
is
warning
even
though
that
job
failed
their
unit
tests,
job
drove
on,
and
it
was
allowed
to
complete
okay,
great
stuff.
Let's
move
on.
A
A
Any
notes
in
the
chat
would
be
great.
A
Okay,
cool.
Thank
you.
Sorry.
My
world
must
be
a
local
issue
for
you
perfect.
So
it's
pretty
common
pattern.
Basically
I
was
saying
there
first
to
hear
from
automation,
Engineers
who
are
trying
to
find
ways
to
add
scans
to
development
Pipelines,
it's
pretty
normal
for
us
to
find
that
in
our
organization
may
already
have
its
own
good
Enterprise
scanners
and
that
these
scanners,
that
they
have
are
generally
unused
by
development.
The
barrier
of
entry
for
using
these
scanners
is
very
high
because
of
the
learning
curve
for
how
to
run
them
is
very
high.
A
There's
no
place
for
scans
to
be
naturally
integrated
into
their
two
or
four
week.
Development
cycle,
like
Sprints,
is
another
thing
that
we
hear,
so
this
problem
is
widespread
enough.
That
gitlab
now
has
an
entire
team
that
focuses
on
creating
these
scanning
jobs
that
can
be
added
to
your
pipelines
and
making
the
whole
barrier
to
add
scans
running
and
pipelines
practically
zero.
It's
great
news,
but
how
do
you
actually
add
gitlab
SAS
into
your
Pipelines?
A
It's
really
simple,
the
documentation
simply
says
add
a
template
and
Wiley
can
definitely
just
copy
and
paste
that
code
out
of
our
documentation
and
into
your
CIA
yaml
file.
It'll
be
good
to
understand
exactly
what
is
a
template
template,
so
you
can
see
here.
It
just
says
add
this
following
thing
to
your
this
following
piece
of
code,
your
gitlab
CIA
yaml,
which
says
include
template
jobs,
SAS
dot,
gitlabs
here
yaml.
A
So
a
template
is
how
gitlab
engineering
is
able
to
share
pipeline
jobs
with
you.
It
is
also
the
way
that
you
can
share
cicd
best
practices
with
other
teams
throughout
your
organization,
so
templates
are
not
magical,
they're,
not
mysterious,
and
once
you
take
a
look
inside
one
which
we
will
do
in
a
minute,
you'll
see
that
they're
all
just
gitlab
cicd
yaml
files
and
all
of
the
Syntax
for
the
CI
stages
jobs.
A
It
also
applies,
and
so
you'll
be
able
to
clearly
understand
the
jobs
that
you
are
adding
to
your
pipeline
by
leveraging
these
templates
and
let's
pull
one
up
here,
I'll
see
if
I
can
yeah
have
it
here.
So
here's
a
code,
quality
template
and
you
can
see
I
mean
it
follows
the
exact
pattern
that
we're
used
to
seeing
here
and
there's
nothing
strange
or
different
about
it.
A
They're
just
templates
that
are
made
available
from
gitlab
engineering
that
you
can
utilize
in
your
own
Pipelines
see
if
I
can
get
another
example
in
a
while
of
another
one
and
but
for
now
that's
that
you
can
note
as
well
that
there
are
different
types.
A
Sorry,
let's
put
this
back
off
for
you,
so
you
can
see
that
there's
different
types
of
include
template
right,
so
the
one
I
just
showed
you
there
was
include
template
that
template
could
be
the
SAS
job.
It
could
be
the
code
quality
job,
which
is
actually
what
I
mentioned
right
at
the
start
of
this
presentation,
when
I
said,
actually,
we
provide
you
with
some
called
quality
jobs.
This
is
how
you
include
it.
If
you,
if
you
want
to
give
that
a
shot,
but
you
can
see
include
template
is
different.
A
That's
how
you
do
that
to
include
local
file
a
remote
and
or
if
repos
are
public,
you
can
actually
publish
these
or
consume
them
from
the
community.
That's
outside
your
organization
as
well,
so
it's
just
worth
noting
that
you
have
these
different
options
for
including
templates
in
your
pipeline
jobs
from
different
sources.
You've
got
include
template,
which
is
from
gitlab
engineering
or
file
remote
local.
That
could
be
from
your
own
organization
or
another
one
that
has
shared
it
publicly.
A
A
A
So
remember
the
predefined
variables
that
we
discussed
earlier.
We
can
see
in
this
SAS
template
exactly
how
they're
defined
so
to
the
left
hand,
side.
You've
got
your
your
variables
how
they're
defined
and
the
SAS
job
that
actually
gets
included,
and
you
can
see
the
variables
here
where
you
can
set
them.
Also
again
this
this
slide
that
could
be
shared
after
the
presentations.
You
can
actually
go
into
the
SAS
documentation.
You
can
go
into
the
SAS
template,
take
a
look
at
it
and
and
as
well.
A
A
A
Again.
All
of
this
is
covered
extensively
in
our
documentation,
so
feel
free
to
have
a
good
Deep
dive
on
that
later.
If
it's
something
you
want
to
explore
more,
let's
talk
a
little
bit
about
artifacts,
so
you
can
get
to
artifacts
from
a
variety
of
places
actually
in
DUI,
and
you
can
download
any
of
the
artifacts
for
a
pipeline
and
the
pipelines
page
or
for
a
specific
job
on
the
jobs
page
or
the
jobs.
Details
page
for
a
specific
job
and
they'll
all
be
downloaded
as
a
zip
file.
A
The
jobs
Details
page
also
gives
the
option
to
browse
the
artifact
save
so
that
you
can
see
all
of
the
directories
and
files
saved
for
that
job
instead
of
having
to
download
the
whole
zip
file.
Art
facts
are
also
available
directly
via
the
API
for
scripted
operations
and
we've
included
documentation
links
in
the
references
that
you
can
check
this
checkout.
A
So
in
our
simple
pipeline
for
build
and
unit
tests,
we've
already
used
the
artifacts
keyword
to
store
the
disk
directory
and
contains
the
results
of
the
build.
We
have
set
the
artifact
to
expire
in
an
hour,
but
even
after
an
artifact
expires,
it's
not
actually
deleted
until
a
newer
artifact
becomes
available,
so
it'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
here
and
that's
that
you
must
have
appropriate
permissions
to
view
and
download
artifacts
so
for
public
projects,
any
users
with
guest
permissions
are
greater,
can
view
and
download
them
and
for
private
projects.
You
need
report
or
permissions
or
greater
to
do
that.
A
A
We
won't
be
completing
them,
live
in
the
workshop,
but,
as
I
said,
you'll
have
access
to
your
training
environment
for
another
four
days,
so
you
can
feel
free
to
visit
the
optional
ones
after
this
for
transfer
to
project
or
the
optional
zest
for
security
and
compliance
and
complex
and
multiple
workflows,
I
highly
recommend
you
leverage
what
we've
provided.
You
would
hear
today
in
terms
of
the
ultimate
training
environment
for
the
next
couple
of
days
and
also
the
instruction
set
so
to
either
go
back
over
it
or
to
try
out
the
optional
steps.
A
A
A
A
So
I'm
going
to
paste
it
incorrectly.
My
apologies
should
go
under
the
image
lines
if
you
should
read
image,
node,
17
and
then
below
it.
We're
going
to
paste
in
the
include
template
so
now
to
take
a
look
at
the
template
that
we
just
added
look
near
the
top
of
the
edit
page.
Next
to
where
you
can
select
the
branch
and
there'll
be
a
tree,
expand
icon.
So
what
they're
talking
about
here
is
this
guy
right
there.
So
yours
might
look
like
this
or
it
might
look
like
that.
A
But
regardless
that's
the
icon
or
talk
Road,
it's
beside
your
branches,
it's
super
handy
and
because
what
it
allows
you
to
do
is
to
go
and
explore
these
templates
like
I
suggesting
when
we
were
looking
at
the
slide
deck
to
see
what's
in
them
and
what
they
do.
So,
if
you
click
on
this
icon
expands
out
like
this,
you
can
click
on
this
guy
right
here
and
that's
the
template
and,
as
I
said
before,
there's
no
mystery
or
magic.
Here,
it's
very
simple!
A
Perfect,
so
we
then
want
to
click
the
link,
as
I
said.
That's
just
to
show
it
to
you,
that's
fine!
You
can
also
click
the
view,
merge
yaml
to
see
the
completed,
yaml
output.
So
if
you
want
to
view
the
merge
yaml,
that's
basically
to
to
to
show
everything.
So
all
of
this
yaml
here
for
your
gitlab
ciml,
including
the
ammo,
that's
included
in
the
SAS
yaml,
will
be
seen
by
clicking
on
full
configuration.
A
A
So
our
sash
jobs
have
been
added
to
the
pipeline
because
we
included
a
template
and
they'll
run
in
time
again.
We
won't
wait
here
for
them
to
run
we'll
we'll
drive
on
to
our
next
step.
I'm
conscious
we're
about
to
come
up
on
time
as
well,
so
using
inheritance,
enhancer
pipeline.
So
let's
go
back
to
our
pipeline
editor.
We
go
to
build
and
pipeline
editor
and
we
first
want
to
add
in
a
new
stage
called
security.
So
I'm
going
to
do
that
here
and
spell
it
correctly.
A
It'll
help
security
new
stage,
and
then
we
will
create
a
new
sashot
that
will
override
some
of
the
functionality
from
the
template.
We
included
the
blow
code
sets
up
a
new
job
and
has
it
run
as
soon
as
the
pipeline
begins.
A
So
I'm
just
going
to
add
that
job
in
there
and
before
committing
the
code,
we're
going
to
add
the
artifact
keyword
in
The,
Next
Step.
So
let's
say
requirement
comes
in
that
we
want
to
store
the
results
of
the
build
app
job
in
an
artifact.
Let's
add
a
change
to
the
job
to
do
just
that,
so
it's
to
build
that
job,
that
we're
changing
and
to
do
so
to
make
it
quick
and
easy
I'm
just
going
to
copy
this
whole
block.
A
So
that's
all
of
our
build
up
job
now
and
I'm
going
to
replace
it
with
the
code.
That's
there
you
can
see
what
we're
defining
here
is
an
artifact,
so
we're
saying
store
the
the
output
of
these
jobs
in
this
artifact
here
so
now.
What
we
want
to
do
is
go
ahead
and
click
on
Commit
changes
and
again
we're
going
to
go
back
to
build
and
Pipelines
and
you'll
see
the
the
latest
one
running.
A
A
A
Now
this
is
something
that
we
can
kind
of
read
through
after
the
session
yourselves
once
you've
got
this
far
it's
going
to
be
running.
It
might
take
some
time
to
complete,
but
it's
worth
just
have
a
read
through
here,
so
you
can
see
the
changes
that
took
place
by
using
the
inheritance
and
disaster.
That
was
this
video
up
here
that
we
added,
and
also
by
including
the
artifacts
you're,
going
to
have
a
number
of
different
ways
to
see
those
artifacts
right.
A
Now
folks,
I
know
we're
just
up
on
time
and
the
transfer
project
and
or
sorry
to
transfer
a
step
and
the
other
two
steps
as
well
they're
optional.
We
don't
need
to
do
them
here
today.
I
won't
be
doing
them
live
on
screen,
but
I'd
like
to
thank
you
all
for
attending
today.
I
hope
you
got
some
value
from
the
session
from
the
workshop.
A
If
you
do
have
any
follow-up
questions
you
can
reach
out
to
me,
my
email
is
there.
As
I
said,
you
have
access
to
the
training
environment
for
the
next
four
days.
Use
it
it's
an
ultimate
account
for
free
work,
your
way
through
the
optional
steps,
if
you
can
and
yeah,
we
appreciate
you
being
here.