►
From YouTube: Intro GitLab CI/CD - April 19th, 2022
Description
Come and learn about what is CI/CD and how it can benefit your team/organization. We will cover an overview CI/CD and what it looks like in GitLab. We will also cover how to get started with your first CI/CD pipeline in GitLab and the basics of GitLab Runners.
A
A
All
right
looks
like
we
have
a
a
number
of
people
in
here
now,
so
let's
go
ahead
and
get
started.
My
name
is
taylor.
I'm
a
member
of
the
customer
success
team
here
at
gitlab
and
I'm
joined
by
my
colleague,
kevin
chase,
who
is
a
staff
technical
account
manager,
we're
happy
to
have
him
on
board,
but
before
before,
I
turn
it
over
to
him
just
wanted
to
go
through
a
couple
of
housekeeping
items
today.
A
First
off
this
webinar
will
be
recorded,
so
you
can
look
forward
to
to
seeing
that
we'll
be
hosting
it
on
our
on
our
youtube
channel.
In
addition
to
that,
as
questions
come
up
throughout,
please
go
ahead
and
put
those
in
the
q
a
we
have
time
reserved
at
the
end
for
kevin
to
answer
some
of
those
and
we
we
may
be
able
to
answer
some
throughout
as
well
by
by
typing
answers
back
to
you
in
the
meantime,
and
with
that
I
will
turn
it
over
to
kevin.
B
All
right,
great
thanks
taylor.
So,
as
taylor
mentioned,
my
name
is
kevin
chassis.
I
am
been
a
tam
here
at
git
lab
for
over
three
years.
I
work
in
the
public
sector
team,
but
we
are
supporting
these
sessions
globally
and
with
me.
Also,
today
is
another
senior
tam
uber's
gonna
be
helping
with
some
of
the
questions.
So
thanks
for
for
helping
out
with
that
all
right.
Well,
let's
go
ahead
and
dive
right
in
so
today
we're
gonna
talk
about
what
is
ci
cd.
B
B
And
now
we
have
a
single
application,
that
is,
for
the
entire
devops
life
cycle,
where
you
have
a
single
login,
single
security,
single
database,
single
user
interface
and
there's.
There's
no
integration
points
within
any
of
the
different
aspects
of
our
our
feature
sets,
and
that
makes
it
for
a
great
developer
experience,
so
so
that
is
a
little
bit
about
get
lab.
So
what
is
the
icd?
You
may
be
brand
new
to
this,
so
cicd
cia
stands
for
continuous
integration.
B
Basically,
the
idea
of
continuously
integrating
and
merging
and
testing
your
code,
rather
than
doing
that
as
a
big
chunk
at
the
end.
So
I've
worked
on
development
teams
where
we
would
work
on
a
release
or
a
sprint,
and
then,
at
the
end
of
that
process
we
would
go
through
the
process
of
merging
all
the
code
together.
Building
it
and
testing
it
and
inevitably
problems
would
arise
and
it
would
be.
B
You
know
a
couple
of
all-nighters
right
before
the
due
date
for
a
release
and
to
get
everything
working
and
it
was
frustrating
and
and
difficult.
So
ci
tries
to
solve
that
problem.
We'll
see
how,
in
a
moment,
cd
is
actually
kind
of
an
overloaded
term.
It
can
stand
for
either
continuous
delivery
or
continuous
deployment.
B
Now
does
this
so
we
as
as
we're
working
on
our
monthly
release,
which
is
released
out
to
our
self-managed
customers,
gitlab.com,
is
actually
updated,
as
each
merge
request
is
approved
and
we'll
talk
about
that
in
a
moment,
but
and
so
features
they're
going
into
gitlab.com
as
soon
as
they're
ready,
which
is
continuous
deployment.
But
then
the
self-managed
release
that
goes
out
once
a
month
from
the
22nd,
which
would
be
more
continuous
delivery,
and
so
we
effectively
kind
of
do
both
here
at
getlab.
B
So
why
use
ci
cds
so,
as
I
talked
about
earlier,
cicd
allows
you
to
detect
errors
quickly,
so
you
can
fix
them
while
they're
fresh
in
your
mind.
So
if
you
introduce
a
problem-
and
you
don't
even
realize
you
did-
and
maybe
it's
only
a
problem
when
your
code
is
merged
with
other
folks
code,
you
can
find
that
very
quickly
and
while
the
change
is
still
fresh,
your
mind,
rather
than
weeks
or
even
months,
light
later
down.
The
road,
as
I
mentioned
in
my
example,
also
ci
reduces
integration
problems.
B
So
any
of
those
those
merge
or
other
issues
are
found
again
quickly.
It
allows
your
team
to
move
faster
so
because
you're
tackling
these
problems
when
they're
small
and
easy
to
fix
it,
allows
your
team
to
move
faster
and
also
have
more
confidence,
not
only
within
your
development
team.
They
can
have
confidence
that
what
they're
doing
is
going
to
be
successful,
and
it's
not
going
to
be
this
huge
stressful
process
at
the
end
of
the
release
cycle.
B
You
don't
have
to
use
gitlab
this
way.
Gitlab
is
very
flexible.
You
can
use
any
workflow
really
that
you
want
with
gitlab,
but
this
is
kind
of
our
recommended
workflow
and
let
me
just
walk
you
through
it
fairly
quickly.
So,
if
you
imagine
this
bottom
line,
is
your
default
production
line
of
code
branch
of
code?
B
You
start
by
creating
an
issue
in
git
lab,
and
this
issue
is
where
you
discuss
with
your
team
and
your
even
your
stakeholders
on
what
you're
gonna
do,
how
how
big
a
change
it
is.
What's
the
risks,
what
are
the
priorities,
the
severities
all
of
those
types
of
things
you're
discussing
in
the
issue
once
you
decide
you're.
Finally,
gonna
assign
this
issue
to
a
sprint
or
a
release.
B
You
can
also
have
optional
approvals
and
once
any
change
will
reset
all
of
these
rerun,
the
pipeline
rerun
the
scans
redeploy
and
allow
you
to
continue
those
discussions
until
finally,
everyone's
happy
with
the
change
it's
past
all
of
your
tests,
your
stakeholders
are
happy
with
it.
Now
you
can
merge
with
confidence.
You
merge
the
issue
merge.
The
merge
request
back
into
the
main
branch
issue
is
automatically
closed,
and
now
your
deployment
pipelines
can
run.
B
B
So
this
visual
kind
of
gives
you
an
idea
of
how
cicd
pipelines
work
and
basically
the
idea
is
you
have
your
code
and
you
can
even
pull
in
related
code
from
other
projects
or
even
other
instances.
If
you're
pulling
in
open
source
code,
you
can
pull
them
in
from
other
places,
other
repositories,
and
ultimately,
all
of
that
gets
pulled
in
and
and
changed
with
a
commit
to
the
branch
that
you're
on
and
that
commit
really
is
just
effectively
a
change.
B
It
just
represents
what
has
changed
from
the
previous
state
of
the
code
to
the
current
state
and
then
within
your
ci
pipeline.
What
you're
generally
going
to
do
is
you're
generally
going
to
have
a
build
of
your
code.
You
could
have
any
number
of
unit
tests
run
any
number
of
integration
tests.
You
actually
can
also
have
automated
ui
testing
if
you're
using
tools
to
do
automated
user
interface
testing.
B
You
could
also
do
those
here
within
the
ci
pipeline
tools
like
selenium
or
other
tools
can
be
called
from
the
jobs
that
get
generated
in
your
pipeline,
and
then
those
results
can
be
fed
back
to
you
and
we'll
talk
about
what
that
looks
like
in
a
moment
and
then
in
terms
of
the
deployment
side,
you
generally
would
you
know,
could
deploy
out
to
a
review
or
a
test
area.
This
could
be
a
dynamic
review,
app
in
kubernetes
or
docker,
or
it
can
be
a
it
could
be
a
static
test
environment.
B
Potentially
you
can
also
deploy
out
to
staging
environments
and
then,
ultimately,
out
into
production
and
there's
a
lot
of
different
options
for
this,
depending
on
what
your
architecture
is
and
we'll
talk
about
some
of
those
options
coming
up
all
right.
So
what
does
this
actually
look
like
in
gitlab?
So
at
the
bottom?
B
Here
you
can
see
what
a
typical
pipeline
graph
looks
like
we
have
across
the
top
is
the
different
stages
you
can
optionally
create
your
pipeline
in
stages,
stages,
help
you
to
kind
of
group
different
jobs
together
and
jobs
are
the
ovals
here
that
represent
individual
pieces
of
work.
The
jobs
are
what
the
system
is
doing
to
actually
do
the
build
and
execute
the
tests
and
get
those
results
back.
B
Jobs
are
executed
by
runners,
we're
going
to
talk
about
runners
at
the
end,
but
runners
are
separate
pieces
from
from
get
lab
that
actually
run.
The
jobs
by
default
stages
are
designed
to
be
sequential,
so
in
this
case
the
build
stage
with
its
one
job
would
run,
and
when
that's
once
that
was
completed,
if
it
was
successful,
the
all
of
the
test
jobs
would
fire
off
in
parallel.
B
So
within
a
stage,
jobs
are
parallel,
but
then
this
next
stage
is
going
to
wait
until
all
three
of
these
jobs
run
before
it
kicks
off
and
then
once
it's
completed,
then
you
can
have
a
deployment
and
you
can
see.
In
this
example,
we
have
some
manual
jobs
which
we'll
talk
about
in
a
minute
where
it
waits
for
someone
with
permissions
to
hit
the
play
button,
and
then
it
automatically
does
the
deployment
for
you.
So
you
can
control
the
sequencing,
whereas
these
other
ones
are
going
to
happen
automatically.
B
So
what
are
different
ways
that
you
might
trigger
a
pipeline
in
gitlab,
so
we
talked
already
about
when
you
push
code
to
your
repository,
it's
going
to
automatically
trigger
a
pipeline.
This
is
by
default.
You
can
change
this
if
you
want,
but
the
idea
is,
every
time
you
push
a
change.
Gitlab
is
going
to
rerun
the
ci
pipeline.
Just
to
give
you
those
results,
so
you
can
see
at
the
smallest
value
of
change,
whether
you've
made
things
better
or
worse
and
so
on.
B
B
You
can
create
schedules.
So
if
your
team
is
currently
doing
daily
builds,
weekly
builds
nightly,
builds
whatever
you're
doing.
You
can
actually
create
a
schedule
and
not
have
your
pipeline
triggered
by
the
push-up
code.
If
you
want
you
could
do
both,
you
could
have
it
triggered
by
the
push,
as
well
as
a
schedule.
If
you
wanted
to,
you,
can
also
have
it
triggered
by
an
upstream
pipeline.
So
another
project's
pipeline
could
trigger
your
pipeline
and
and
cause
it
to
run.
We
will
talk
about
that.
B
B
B
Yaml
is
a
markup
language,
that's
industry
standard,
but
in
in
in
this
case
we
are
using
it
to
define
all
of
the
aspects
of
our
ci
and
our
cd.
So
originally,
when
we
named
this,
it
was
originally
just
ci.
We
added
the
the
cd
later,
but
the
name
of
the
file
is
still
ci.
Now
you
can
have
multiple
yaml
files
and
then
combine
them
together.
B
If
you
want,
we
cover
that
in
the
advanced
session
today,
we're
gonna
be
focused
on
a
single
file
and
we're
gonna
go
through
the
process
of
explaining
what
each
of
these
are
in
a
moment
and
actually
go
through
the
process
of
building
one
of
these
out
in
the
slides.
You
can
you'll
get
a
copy
of
these
slides
and
you
can
follow
this
yourself
to
set
up
your
own
pipeline
when
you,
after
the
session,
so
as
we
saw
earlier
there
are
you
define
the
stages.
B
Now
here
is
an
example
of
an
individual
job,
so
this
is
the
name
of
the
job
you
define
what
stage
it's
going
to
be
in.
You
define
what
it's
going
to
do
using
the
script
and
there's
a
couple,
different
options
for
that
which
we'll
go
into
in
a
moment,
and
you
also
have
a
way
to
control
when
this
job
is
going
to
fire.
B
But
you
can
also
use
a
more
complex
rules
system
that
we
have
implemented
in
the
last
couple
years.
That
allows
a
lot
more
control
and
then
finally,
here's
another
example
of
a
deployments
job.
Again
we
define
what
stage
it's
in
what
it's
going
to
do,
but
in
this
case
it
needs
information
about
where
to
deploy
to
you.
B
B
That
goes
through
all
of
the
different
reference
values
that
you
can
possibly
have
within
your
ci
configuration,
and
these
keywords
will
help
you
to
control
exactly
what's
going
to
happen
in
your
pipeline
and
we're
going
to
go
through
several
of
them
today,
but
we're
not
going
to
have
time
to
go
through
all
of
them
so,
and
this
just
gives
you
all
of
the
details
for
all
of
the
configurations,
I'm
not
going
to
go
through.
Everything
today
is
just
showing
you
some
examples,
but
we
will
hit
several
of
these
today.
B
So,
as
I
mentioned,
there
are
four
default
stages
that
are
built
into
gitlab.
If
you
don't
declare
these,
you
can
still
assign
jobs
to
these
stages.
Again,
though,
for
readability,
I
highly
recommend
that
you
declare
them
so
that
others,
when
they're
viewing
it
can
easily
follow
along
with
what's
going
on.
But
those
four
default
stages
are
build
test
review
and
deploy.
B
B
Jobs
are
the
workhorse
right.
This
is
where
the
actual
work
is
being
done.
Everything
else
is,
is
really
configuring
the
sequencing
and
the
order,
but
once
you're
in
a
job
you
are.
This
is
where
it's
actually
doing
the
build
running
the
tests,
whatever
it
is,
and
so
the
the
core
part
of
a
job
is
the
script,
that's
going
to
define
what
that
job
is
going
to
do
anything
that
you
could
do
via
the
command
line
or
including
making
api
calls
everything
you
can
do
inside
the
script
of
a
job.
B
You
can
have
the
script,
be
a
file
in
your
repository
when
a
job
is
run,
it
actually
pulls
down
the
code
from
your
repository,
so
it
has
access
to
all
of
the
files
within
your
repo
so
that
it
can
do
the
build
it
can
do
and
it
can
use
script
files
as
well
and
if
you're
on
windows
these
could
be
batch
files
as
well.
These
are
examples
here
are
our
linux
script
files?
So
so
you
could
have
a
single
script
file
and
everything
is
defined.
B
Within
this
separate
file,
you
could
have
a
separate
file
that
is
in
a
different
directory
within
your
code
base,
or
you
could
have
just
a
single
command
that
is
going
to
get
executed
or
you
can
have
a
sequence
of
commands
and
you
can
even
have
a
sequence
of
scripts
that
run
so.
This
is
showing
you
several
different
examples,
so
you
can
actually
have
the
commands
that
you
would
run
explicitly
within
your
ci
file
or
you
can
have
them
in
a
related
file.
That's
gonna
execute
at
the
time
that
the
pipeline
runs.
B
All
right,
so
this
is
a
another
example
of
some
of
the
the
different
basic
parameters
of
that
you
can
have
within
the
definition
of
these
jobs,
and
so
we
have
three
different
jobs
here:
test
staging
and
production.
Again,
we've.
We
have
a
couple
different
scripts
here,
the
the
this
one's
going
to
execute
this
series
of
commands
in
order-
and
you
notice
there's
no
stage
here.
So
if
the
name
of
your
job
represents
one
of
those
four
default
stages,
it
knows
hey.
B
B
Again,
I
highly
recommend
you
don't
do
this-
that
you
actually
explicitly
describe
what
stage
that
job
is
going
to
execute
in
just
for
readability,
but
you
you
can
because
of
those
special
words
you
can
do
that
on
your
own
and
then
you
can
see
some
examples
here
where
we've
we've
done
a
couple,
different
examples,
so
in
here
we've
got
this
job
is
only
going
to
run
so
this
test
job
has
no
only.
That
means
it's
going
to
run
every
time.
B
The
pipeline
runs,
the
staging
is
only
going
to
run
when
the
code
is
merged
back
into
main
or
a
commit
is
made
directly
to
me.
So
this
would
run
on
your
feature
branch.
This
would
run
when
your
feature
range
is
merged
back
into
main
and
then
finally,
this
production,
one
that
deploys
to
a
production
environment,
is
only
going
to
run
when
your
code
has
been
a
git.
B
Tag
has
been
applied
to
your
code,
so
if
your
process
is
feature
branch
test,
maybe
your
build
job
would
also
be
here
with
these
two
with
no
only
and
then
you
could
have
a
staging
job
when
it
merges
into
main
and
then,
when
you
apply
a
tag,
that's
when
it
deploys
out
into
production.
So
this
just
shows
you
an
example
of
how
you
can
control
these
things
with
a
simple,
only
and
accept
which
we'll
get
into
in
a
moment.
B
Now,
if
you're
using
docker,
you
need
to
be
able
to
tell
git
lab
what
image
you
want
to
use
now,
if
you're
not
using
docker,
this
wouldn't
apply
and
we'll
talk
about
at
the
end,
with
the
runners,
some
of
the
different
options
that
you
have,
if
you're,
not
using
docker
or
kubernetes
or
another
container
service,
but
your
images.
So
if
you
just
specify
a
very
simple
image,
this
is
gonna,
go
out
to
docker
hub
and
try
and
find
this.
If
it
can.
B
If
you
want
to
specify
a
different
location,
you
can
specify
the
full
path
to
a
custom
image.
In
this
case.
This
is
an
image
in
a
git
lab
repository
container
registry
on
gitlab.com,
but
it
could
be
your
own
container
registry.
If
you
have
your
own
container
registry
behind
your
firewall
that
you
want
to
utilize,
you
can
specify
the
what
image
to
use
the
name
of
the
image
and
the
version
and
everything
so,
and
this
is
done
with
a
single
image
line.
B
This
means
that
by
default,
every
job
is
going
to
use
this
image
by
default.
You
can
override
this
with
an
individual
job
which
I'll
show
you
in
a
moment
now,
if
you're
using
docker,
you
may
also
need
associated
services
that
you
need.
So
in
that
one
container,
you
may
not
have
everything
you
need,
and
so
you
may
need
some
additional
containers
to
do
your
your
tests,
and
so
in
this
case
you
can.
You
can
provide
services
that
the
runner,
then
an
additional
image,
will
be
needed.
B
So
in
this
case
it's
gonna
pick
up
a
postgres
one.
You
can
also
specify
variables,
so
there
are
lots
of
built-in
variables
to
gitlab
that
tell
you
information
about
the
specific
commit
and
what
triggered
it
and
all
that
other
good
stuff.
But
you
can
create
custom
variables
as
well
to
pass
information
to
your
jobs.
The
nice
thing
about
these
variables
is,
you
can
also
when
you
do
a
manual
or
a
scheduled
pipeline,
you
can
specify
different
value
for
these
variables.
B
Earlier
you
saw
an
example
with
environments.
Environments
are
a
way
to
define
where
your
application
will
be
deployed
and
basically
allows
you
to
tell
give
it
a
name
for
what
this
environment
is
going.
To
look
like
this
is
important,
because
within
the
user
interface
of
gitlab,
you
can
actually
view
these
environments
and
it's
going
to
use
the
names
provided
here.
B
B
So
in
this
case,
we've
provided
a
manual
meaning
that
that
job
that
this
environment
clause
is
part
of
will
be
a
manual
job.
What
that
means
is
that
it
will
get
that
play
button,
that
we
saw
in
the
very
first
pipeline
that
you
saw
it'll,
get
that
play
button,
which
means
that
the
triggering
of
it
will
be
manual.
But
then
the
process
of
deployment
will
still
be
automated.
B
B
So
that
would
mean
that
you
know
a
a
tag
won't
trigger
it,
but
but
in
this
case
we
don't
want
it
to
trigger
when
the
change
is
made
to
the
main
branch.
So
this
would
only
affect
feature
branches,
for
example,
in
this
example,
but
it
won't
affect
main
branch,
so
this
this
job
will
run
on
feature
branches,
but
not
on
your
main
branch.
B
We
do
have
a
rule,
syntax,
there's
a
link
here.
If
you
want
to
look
at
more,
we
will
go
into
more
detail
in
about
rules
in
the
advanced
session,
which
I
think
is
is
coming
up.
If
not
we
can
we
can
schedule
one
of
those,
but
we
do
an
advanced
session
of
these.
That
has
goes
into
a
lot
more
detail
on
the
rules
and
just
to
show
you
an
example
of
what
that
looks
like.
So
the
only
except
is
very
simple,
but
it's
not
very
powerful
rules.
B
This
is
the
exact
same
combination
of
as
the
one
we
just
saw.
So
what
this
is
saying
is
if
the
branch
that
it
was
committed
to
was
mean
then
never
include
this
job.
Otherwise
always
include
this
job
and
we'll
go
into
more
detail
in
that
in
a
future
session.
But
let's
just
give
you
an
example
of
what
the
exact
same.
Only
an
except
block
would
look
like
a
as
a
rules
block,
but
you
have
a
lot
more
combinations
with
the.
B
You
also
have
the
option
to
include
before
and
after
scripts,
in
your
ci,
the
fourth
script.
If
you
define
it
outside
of
a
job,
it
will
be
applied
to
every
job
same
with
the
afterscript
and
the
before
script
is
literally
just
concatenated
to
the
front
top
of
whatever
your
script
is
for
each
job.
So
it's
as
if
you
had
copied
and
pasted
this
into
every
single
script
for
every
single
job.
B
If
you
declare
it
outside
of
a
job,
the
after
script
is
a
little
bit
different
after
script
will
run
at
the
end
of
the
job,
even
if
the
job
failed.
So
it
gives
you
an
option
to
clean
stuff
up.
This
is
great,
especially
if
you're
using
static
deployment
sites
or
static
environments
or,
if
you're,
not
using
docker,
where
you're
getting
a
fresh,
clean
environment,
you
need
to
make
sure
everything
is
clean
for
the
next
run,
or
you
need
to
clean
everything
up
with
your
before
script.
B
B
So,
let's
talk
a
little
bit
so
now
that
you
have
you
have
all
these
different
jobs,
you
have
a
build
job
and
then
a
test
job.
But
well
what's
the
point:
if
of
having
a
separate,
build
job,
if
right
this
docker
image,
that's
going
to
get
my
test,
job
doesn't
have
the
results
of
the
build
it
has
to
rerun
the
build.
So
why
do
I
need
to
build
a
job
at
all?
Well,
you
can
pass
temporary
files
and
artifacts
between
jobs
using
the
cache
and
artifacts.
So
the
main
difference
is
cash
is
temporary.
B
When
the
pipeline
is
done,
the
cash
is
no
longer
accessible.
If
you
do
want
it
to
be
accessible,
you
can
use
artifacts
instead,
both
are
very
similar
because
you
can
specify
a
path.
So
you
can
say
anything.
This
job
generates
is
going
to
be
stored
as
an
artifact
for
cash
to
be
passed
down
to
future
jobs
in
future
stages,
and
so
in
this
case
it's
saying
anything,
that's
in
the
binary
directory
or
any
file
with
dot
config.
B
In
this
case,
it's
it's
everything
in
this
bin.
Slash
target
directory.
Just
to
show
you
a
couple
examples
with
the
artifacts
you
can
also
say:
I
only
want
to
store,
because
I
only
want
to
start
the
artifacts
if
the
job
was
successful
is
so
there's
some
options
with
the
when
keyword
which
we'll
get
into
later.
B
Okay,
so
what
does
our
file
look
like?
Now?
We
have
everything
that
we've
already
added
with
our
environments
and
our
only
and
our
images
and
everything-
and
then
we
add,
we're
gonna,
add
this
cache
and
because
I
added
the
cashier
outside
of
a
job,
it
means
that
every
job
is
going
to
use
the
binary
directory
as
it's
as
its
cash.
So
anything
that's
going
to
generate
it
into
the
binary
directory
will
be
stored
by
gitlab
and
passed
to
the
next
job.
But
then
at
the
end,
none
of
it
will
be
available
long
term.
B
So
it's
temporary
and
then
we're
going
to
go
ahead
and
add
this
additional
job
and
then
I'm
going
to
define
artifacts
within
this
job,
so
the
build
is
going
to
store,
in
addition
to
caching
everything
in
the
binary,
it's
going
to
store
as
an
artifact
everything
in
the
bin
target
folder.
So
you
can
actually
use
both.
You
can
combine
both
together.
B
B
So
if
you
know
that
you
need
a
runner
and
we're
getting
into
runners
in
the
moment,
if
you
know
you
need
a
runner
that
has
a
certain
operating
system
like
windows
or
linux
or
mac
or
you
know
you
need
to
get
to
one,
that's
a
specific
resources
available,
or
maybe
there's
a
target
machine
and
there's
a
runner
that
is
on
that
machine
to
allow
you
to
do
deployments
directly
there,
and
you
want
this
job
to
be
forced
onto
that
runner.
You
can
use
tags.
B
Runners
can
have
any
number
of
tags
to
give
it
kind
of
information
about
what
this
runner
types
of
jobs.
This
runner
is
going
to
do
and
then
jobs
can
have
any
number
of
tax.
But
the
way
that
get
lab
figures
out
is
that
any
runner
that
matches
all
of
the
job
tags
for
a
given
job
will
be
eligible
to
run
that
job.
It
doesn't
matter
if
the
runner
has
additional
tags
that
aren't
mentioned
by
the
job.
B
B
All
right,
so
that
kind
of
gives
you
an
idea
of
all
the
basics
for
what
is
available
within
ci.
Now,
let's
talk
about
runners,
which
is
where
your
all
of
the
work
you've
done
to
declare
all
of
your
pipeline
are
actually
going
to
get
executed
and
then,
after
this
we
will
have
time
for
q
a
okay.
So
how
does
all
of
this
work
so?
First
and
foremost,
you
have
your
gitlab
cif
yaml
file,
which
we
just
went
through
and
just
talked
about
that
defines
what
needs
to
happen.
What
are
the
instructions?
B
B
So
how
does
this
work?
Well?
Basically,
you
don't
want
to
install
runners
directly
on
your
gitlab
server.
We
don't
recommend
that
you
can
have
a
number
of
runner
servers.
You
can
have
a
cluster,
you
can
use
kubernetes,
you
can
use
docker
machine.
You
can
use
lots
of
different
technologies
out
there
to
virtual
physical.
B
You
can
even
install
runners
on
your
individual
laptop
if
you
want
and
what
the
runners
do
is
they
periodically
will
make
an
https
call
back
to
the
gitlab
server.
Basically
saying
hey,
I'm
this
runner
and
I
am
ready
to
take
a
job
and
the
gitlab
server
is
tracking
all
of
the
events
that
have
happened.
You
know
and
it's
like.
Oh
I've
got
a
job
ready
and
you
qualify
I'm
going
to
go
ahead
and
give
it
to
you.
So
the
nice
thing
is
that
the
runners
make
calls
to
the
server.
B
The
server
never
makes
a
call
out
to
the
runner.
When
you
do
register
the
runner,
you
have
to
tell
it
what
where
the
server
is
and
whether
it's
available
to
all
projects
on
the
instance
all
projects
in
a
group
or
or
a
specific
individual
project
which
we'll
talk
about
in
a
minute
generally,
your
administrator
is
going
to
create
these
and
the
gitlab
runner
can
build
and
test
pretty
much
any
any
programming
language.
B
B
Shared
rumors
are
included
in
the
pool
for
all
projects
managed
by
the
get
lab
admin,
and
generally
we
recommend
these
to
be
auto
scaling
or
scaled.
In
some
way.
Specific
runners,
though,
are
only
available
for
specific
projects
generally
managed
by
the
owner
of
those
projects
and
typically
used
for
specialized
builds
or
or
other
specialized
needs.
We
definitely
recommend
using
shared
runners
for
the
most
part,
because
they
can
be
more
efficient
and
using
specific
runners
as
an
exception.
B
Runners
can
be
tagged
or
untagged.
We
talked
about
ci
tags
earlier,
so
if
this
runner
is
tagged
with
windows,
then
this
job,
which
is
tagged
with
windows,
means
this
runner
is
eligible
to
utilize.
This
this
to
run
this
job.
You
can
also
have
tag
runners
that
are
not
tagged
at
all,
which
means
they
will
only
pick
up
untagged
jobs,
and
you
can
also
tell
this
runner.
This
runner
can
also
pick
up
untagged
jobs
just
because
it
has
a
tag.
B
Remember
it's
the
job
that
determines
whether
the
runner
can
run
it
or
not,
not
the
runner.
So
this
will
also
run
untagged
jobs,
but
there
is
a
setting
you
can
set
to
say:
don't
run
untagged
jobs
if
you
like.
So
if
you
don't
want
this
to
pick
up
linux
jobs
as
an
example,
you
could
you
could
tag
it
that
way
and
then
finally,
you
have
protected
versus
non-protected
runner
runners
protected
runners
only
run
jobs
from
protected
branches
and
protected
tags.
B
Typically,
this
is
used
for
runners
that
contain
deployment
keys
or
other
sensitive
that
generally,
these
are
by
far
and
away
the
exception.
Most
runners
are
going
to
be
non-protected
that
run
jobs
from
any
branch
for
any
build,
so
this
would
be
a
good
example
is
if
you
have
a
specialized
deployment
environment
or
something
like
that,
where
you
only
want
it
to
run
from
your
protected
branches
like
your
main
branch
and
so
on,
and
then,
as
I
mentioned,
there
are
additional
runner
options.
B
One
of
the
most
so
the
way
that
the
runner
executes
the
jobs
is
also
important,
and
when
you
register
the
runner,
you
have
to
tell
it
what
kind
of
execution
method
it's
going
to
use
or
what
executor
it's
going
to
use.
The
most
common
ones
are
docker,
kubernetes
and
shell,
so
shell
will
run
directly
commands
as
if
the
person
was
sitting
them
writing
into
the
terminal
for
bash
or
sh
or
command
prompt
repair
shell.
So
they
are
run
on
the
machine
where
the
job
is
going
to
be
run.
B
B
If
you
can
use
docker
kubernetes.
We
highly
recommend
using
those
there's
a
lot
of
advantages.
You
you
get
a
clean
environment
every
time
you
know
with
the
shell
one,
because
it's
the
exact
same
machine
you
could
have
things
left
over,
that
could
inadvertently
affect
future
runs
and
so
on,
but
with
docker
and
kubernetes
you're
not
going
to
get
those
and
and
so
there's
lots
of
different
options
within
those
as
well.
B
You
also
can
use
virtualbox,
parallels
and
ssh
is
similar
to
shell,
but
is
bash
only.
It
doesn't
support
caching,
but
it
does
allow
you
to
ssh
and
execute
commands
on
a
machine
where
you
might
not
want
to
install
the
runner.
So
good
use
case
for
this
might
be
like
if
you
don't
want
to
install
runner
on
your
production
machine,
but
you
want
another
machine
to
deploy
to
it.
B
You
could
use
an
ssh
runner
on
that
machine
where
it
would
actually
execute
the
deployment
and
use
ssh
to
deploy
it
to
your
production
machine
as
an
example.
Again,
if
you're
using
kubernetes
or
similar
technology
for
production,
then
you
would
just
use
a
kubernetes
runner
and
not
have
an
issue
for
that
all
right.
B
So
I
know
that
was
a
lot,
but
let's
go
ahead
and
open
it
up
for
q
and
a
and
if
you
want
to
drop,
if
you
haven't
already
go
ahead
and
oops
sorry
drop
any
questions
you
might
have
into
the
q
a
and
taylor
and
uber,
and
I
will
try
to
answer
those
and
they
can
be
about
what
we
talked
about.
Or
if
you,
if
you
have
a
general
question
about
git
lab
we'd,
be
happy
to
take
those
as
well.
B
Or
if
there's
an
area
that
you
need
me
to
go
back
over
on
in
more
detail,
because
I
know
I
went
pretty
quickly
all
right,
so
our
first
question
is:
is
this
webinar?
Will
this
webinar
be
available?
Where
can
we
find
it
so
taylor?
Can
you
provide
some
additional
information
on
where
you're
gonna
be
posting,
the
recording
and
the
slides
after
the
session.
A
B
Oh
yes,
okay,
so
docker
machine
is
a
it's.
It's
basically
a
way
and
let
me
go
back
to
that
slide.
So
it's
basically
a
way
to
do.
Auto
scaling
runners
without
oops
went
to
the
wrong
slide
without
kubernetes.
So
if
you're
not
ready
to
use
so
kubernetes
is
a
great
option
for
auto
scaling
because
it
can
just
spin
up
ponds
to
host
containers.
B
B
And
feel
free
to
ask
a
follow-up.
If
I
didn't
so
next
question,
do
you
have
documentation
or
examples
of
doing
something
like
feature
environments
and
triggering
different
jobs
on
different
repos?
Yes,
so
there's
a
couple
different
places
you
can
go
for
that
and
and
taylor.
I
believe
we
are
doing
a
advanced
ci
in
the
future
during
this
series-
and
I
know
we
cover
that
in
that
session-
if
we're
not,
we
can
definitely
discuss
doing
it
because
I've
mentioned
it
several
times.
B
B
Otherwise
I
can
take
a
minute
here
if
there's
no
other
questions
and
find
the
link
myself,
but
there
are
a
couple
links
on
our
docs
pages
that
talks
about
how
you
can
use
that
trigger
key
trigger
keyword
to
trigger
additional
pipelines,
either
in
other
projects
or
even
child
pipelines
within
the
same
project.
If
you
have
like
a
mono
repo
architecture,.
B
Okay,
zachary
asks
are
blue,
green
and
canary
deployments
supported.
Yes,
definitely
we
definitely
support
that
and
we
didn't
go
into
those
in
today's
session
because
of
kind
of
you
know
we're
trying
to
get
it
down
to
an
hour
and
just
give
you
the
basics
into
ci
and
cd,
but
we
definitely
support
blue,
green
and
canary.
They
are
available
using
kubernetes,
so
they
can
do
those
with
pods
and
what
it
does
is
it.
B
It
gives
you
you
can
actually
control
whether
where
those
are
going
out
to
you,
you
can
even
do
with
kubernetes.
You
can
even
go
out
to
10
25
of
the
pods
and
define
those
and
those
are
all
again
our
docs
page,
the
details
for
that
are
available.
So
again,
we
can
try
and
get
you
the
link
here
in
the
next
few
minutes
to
that
page
as
well.
B
And
then
next
question:
what
is
the
best
way
to
set
up
one
runner
so
that
the
dev
team
can
deploy
to
the
dev
box,
but
only
sys
admins
can
deploy
to
the
prod
box
yeah.
So
there's
a
couple
different
ways
that
you
could
do
that?
What
I
would
recommend
is
so,
as
we
talked
about
earlier,
you
can
actually
use
the
protected.
B
We
have
a
new
feature
that
we
have
introduced
and
it's
in
a
minimal,
viable
state
that
allows
you
within
your
pipeline
to
create
and
approve
or
reject
step
that
a
person
with
permissions
can
either
approve
the
pipeline
to
continue
or
reject
it.
Based
on,
what's
been.
What's
happened
so
far
to
control
before
going
into
the
next
step.
So
definitely
take
a
look
at
the
new
approve
reject
in
14
9.
If
you
haven't
checked
that
out
already.
B
B
B
A
B
B
Is
there
a
way
to
introduce
ci
cd
in
an
iterative
way?
How
could
we
get
started
with
a
minimum
configuration
and
elaborate
it
step
by
step,
since
we
lack
time
to
do
it
all
at
once?
Yeah,
that's
a
great
question
and
I
I
apologize.
I
really
should
have
mentioned
that
when
I
was
doing
this,
because
that
is
a
key
thing
that
we
hear
from
a
lot
of
folks,
especially
brand
new.
B
What
I
would
recommend
is
like,
depending
on
what
mechanism,
what
what,
if
you're,
using
sprints
or
scaled
agile
framework
or
whatever
each
cycle,
I
would
make
it
a
goal
to
like
just
start
with
a
single,
create
a
single
ci
job.
So
maybe
you
just
do
you
just
have
the
build
automated
by
the
ci
job
and
you
have
no
tests,
no
nothing
else
and
then
the
build
artifacts.
You
can
pull
declare
you
know,
use
that
artifacts
like
we
saw
to,
and
then
those
would
be
available
to
you
you
can.
B
You
can
grab
them
via
an
api
call
or
via
the
ui
and
use
those
artifacts
and
just
manually,
deploy
them
to
your
test.
Environment
manually
run
the
tests,
then
the
next
cycle-
maybe
you
add
in
some
unit
at
a
unit
test
step
and
then
the
next
cycle
you
add
in
some
additional
integration
tests
and
that
way
you
slowly
shift
from
manual
build
and
deploy
and
and
each
cycle
you
make
it
better
and
you're
moving
faster
and
faster.
So
that
would
be
the
recommendation.
B
In
fact,
I've
done
this
with
a
few
personal
projects
where
I
needed
a
specific
library.
I
pulled
a
basic
owen
from
git
from
docker
for
hub
and
then
added
what
I
needed
into
it,
built
that
image
stored
at
my
in
in
the
registry
and
then
used
that
for
subsequent
jobs.
So
that's
something
you
could
totally
do
as
well
to
get
your
prerequisites,
but
yes,
the
runner
will
need
access
to
those
on
the
same
machine.
So
as
long
as
the
the
runner
user
has
access,
you're
good.
B
C
B
Of
information
I
could
go
into
that
with
with
git
ops
and
infrastructure
as
code
and
how
you
can
kind
of
those
work
together.
I
don't
think
I
have
enough
time
to
go
into
that.
Unless
I
don't
know
if
uva
you
have
a
quick
answer
to
this-
that
you
want
to
verbalize,
but
but
but
there's
a
lot
of
information
on
our
docs
page,
but
I
I
think
it
would
just
in
a
minute
or
two
we
have
left.
I
just
don't
think
I
could
go
into
that.
Much
detail.
B
Thank
you
so
much
appreciate
it,
and
then
I
guess
maybe
our
final
question,
because
I
know
I
want
to
give
taylor
a
minute
to
wrap
up
at
the
end
to
let
you
know
about
other
upcoming
resources,
but
I'm
guessing
secrets
are
injected
via
environment
variables.
Is
there
a
way
to
make
sure
secrets
don't
show
up
in
logs
when
a
job
stage
fails?
Is
there
a
way
to
set
a
timeout
for
jobs
and
stages?
So,
yes,
there's
a
couple
different
techniques.
B
You
can
use
to
protect
secrets,
including
our
vault
integration,
which
is
a
great
one
and
in
the
advanced
session
we
definitely
talk
about
that
in
a
little
bit
more
detail
and
how
you
can
use
protected
and
and
hidden
variables,
and
the
values
of
those
variables
can
only
be
seen
by
a
maintainer
or
an
owner,
and
when
you,
if
you
just
try
to
output
them
as
plain
text
in
your
job,
they
will
be
masked
mask.
That's
the
key
word
I
was
looking
for.
B
B
C
B
A
Okay,
great
well,
thank
you,
everybody
for
joining
us
today.
I
think
that
that
was
a
great
session.
You
can
look
forward
to
hearing
from
us,
like
I
said
in
the
coming
days,
with
information
on
on
the
recording
and
when
you
get
that,
please
feel
free
to
to
provide
any
feedback.
Let
us
know
if
there's
anything,
we
could
have
done
better
or
improvements
and
we're
we're
always
looking
to
to
to
make
these
better.