►
From YouTube: Intro to GitLab CI/CD
Description
Come learn about what CI/CD is and how it can benefit your team. We will cover an overview of 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,
let's
kick
things
off
thanks
everyone
for
for
joining
us
today.
We're
we're
excited
that
you
took
some
time
out
of
your
schedule
to
to
join
us.
My
name
is
taylor
lund,
I'm
a
a
manager
of
technical
account
managers
here
at
gitlab,
and
I
am
joined
by
kevin
chassis,
who
is
a
staff
technical.
A
Who
will
be
our
presenter
today
before
I
kick
it
over
to
him
just
a
couple
of
housekeeping
items.
First
off
this
webinar
is
being
recorded,
it
will
be
sent
out
to
all
who
registered
and
attended
in
in
the
next
day
or
two.
So
you
can
look
for
that
in
your
inboxes.
A
If
any
questions
come
up
throughout
the
session,
please
put
those
in
the
q
a
within
the
the
zoom
window.
We
should
have
time
to
to
get
those
answered
and
we're
looking
forward
to
to
a
engaging
session
today,
and
with
that,
I
will
kick
it
over
to
kevin.
B
All
right,
thank
you.
Taylor
welcome
everyone,
as
taylor
said
I'll,
be
taking
I'll,
be
responding
to
questions
live
at
the
end
of
the
presentation,
but
we
do
have
folks
on
that
will
be
responding
to
questions
as
they
come
in
if
they,
if
they
can
so
today,
we're
gonna
be
talking
about
getting
started
with
get
lab.
B
Ci
cd
there's
a
lot
to
cover,
so
I'm
going
to
go
ahead
and
dive
right
in
so
we're
going
to
go
through
what
is
ci
cd,
an
overview
of
what
it
looks
like
in
git
lab
how
to
get
started
with
it,
and
we're
also
going
to
talk
a
little
bit
about
runners,
which
are
the
piece
one
of
the
pieces
behind
the
scenes
that
makes
the
magic
happen
with
gitlab
ci
cd,
and
then
we
will
do
questions
and
answers
at
the
end,
but
feel
free
to
put
questions
in
as
you
think
of
them,
and
my
colleagues
that
are
on
the
call
will
respond
to
to
those
that
they
can
and
then
we'll
take
the
live
questions
at
the
end.
B
Well,
first
and
foremost,
though,
if
you're
brand
new
to
get
love
cd,
you
might
be
also
brand
new
to
gitlab.
So
what
is
git
lab
gitlab
is
a
complete
devops
lifecycle
tool,
bridging
both
development
and
operations
and
even
security,
so
really
a
complete
devsecops
tool.
B
We
started
as
a
git
repository
manager
and
quickly
we
added
the
first
really
major
thing.
We
added
was
ci
or
continuous
immigration
which
we're
going
to
talk
about
in
a
moment,
and
there
was
a
decision,
a
kind
of
a
debate
internally
on
whether
we
would
do
that
inside
the
same
application
that
was
doing
the
git
piece
or
as
a
separate
module
and
integrate
them.
B
And
the
argument,
luckily,
I
think,
from
our
perspective,
was
one
that
we
should
do
in
one
application
and,
as
we've
added
all
the
different
capabilities
that
are
now
available
in
gitlab.
They
are
all
available
in
a
single
application,
which
is
a
really
powerful
thing
and
it
makes
the
process
a
lot
simpler.
So
all
right,
so
let's
dive
into
what
is
ci
cd,
so
ci
kind
of
stands
for
continuous
integration
and
basically
the
idea
of
doing
very
frequent,
builds
and
tests
on
your
code.
So
it
builds
integrations
tests.
B
All
of
that
happening
on
very
small
changes
very
often
and
frequently,
rather
than
waiting
till
like
the
end
of
a
of
a
release
cycle
and
then
only
then
building
and
integrating
and
testing
your
code.
I've
done
that
on
projects
that
I
was
the
the
lead
developer
for
in
previous
lives,
and
that
I
can
tell
you
is,
you
know,
has
all
kinds
of
issues
and
problems
with
it,
and
so
cd
is
kind
of
an
overloaded
term.
B
It
actually
can
mean
two
different
things,
so
it
can
even
be
continuous
delivery
where
software
is
released
to
production
automatically
or
continuous
deployment
where
it's
actually
pushed
out
to
production
and
gitlab,
of
course
supports
both
and
we'll
dive
into
more
detail
in
this
graph
in
a
minute.
So
I'm
not
going
to
spend
a
lot
of
time
on
that
right
now.
B
So
why
use
ci
cd?
Well,
there
are
several
reasons
and
some
of
them
kind
of
believe
what
the
story
I
just
told
about
previous
job
I
had
where
we
would
wait
till
the
end
of
the
process.
You
know
often
a
couple
days
before
a
deliverable
was
due
to
the
customer
and
it
was
very
stressful
when
we
were
all
working
toward
you
know,
past
midnight
and
on
on
those
nights,
and
it
was
crazy.
B
The
beauty
of
using
ci
cd
is
that
ci
can
detect
errors
very
very
quickly.
The
developer
gets
feedback
immediately,
so
if
they
accidentally
break
something-
and
they
don't
realize
it
because
those
builds
and
automated
processes
are
happening
behind
the
scenes
when
they
push
their
code
to
the
server
they're,
getting
feedback
right
away
and
they
can
see
oops,
I
didn't
realize
I
was
gonna
break
the
build
I
didn't
realize.
I
was
gonna
break
this
other
piece
and
they
can
make
a
change
while
it's
still
fresh
in
their
mind.
B
Rather
than
days,
weeks
months
later,
when
they're
you
know
they're
presented
with
hey
this
code
change,
you
may
introduce
this
issue.
Oh,
I
don't
even
remember
what
I
was
doing
and
then
they
have
to
think
about
it
and
they
have
to
go
through
that
whole
process
and
remember
it
come
up
with
a
solution
and
it
takes
longer
so
obviously
along
those
lines.
Ci
also
reduces
integration
problems,
so
you
know
smaller
problems
are
easier
to
fix
and
and
also
make
sure
that
those
problems
don't
compound.
B
So
you
build
confidence
not
only
within
your
team,
but
also
with
your
stakeholders
with
your
customers
right,
because
you're,
detecting
errors
more
quickly,
you're
fixing
them
more
quickly,
isn't
guaranteed
that
no
errors
are
going
to
be
seen
by
the
customer
or
your
stakeholders,
but
it
is
going
to
reduce
it
and
it's
going
to
increase
the
confidence
with
them,
but
also
within
your
own
team,
because
you're,
confident
these
small
changes
are
not
having
a
negative
impact,
and
thus
you
can
move
more
quickly
and
and
so
on,
and
then
cd
ensures
that
every
small
change
is
releasable.
B
You
can
get
that
in
front
of
your
customers
more
quickly
and
get
their
feedback
and
then
that
feedback
can
help.
You
adjust
course,
because
maybe
your
initial
guess
of
the
right
solution
to
a
particular
problem
isn't
the
right
one
and
by
providing
a
small
amount
of
feedback
quickly
you
you
can
adjust
course,
and
you
can
make
changes
and
get
to
the
right
solution
for
your
customers
more
quickly
than
if
you
had
gone
through
and
done
a
complete
and
end
solutions
and
git
lab
embraces
that
philosophy.
B
B
Building
upon
that
and
and
then
adding
features
based
on
feedback,
enhancing
the
feature
that
we
released
as
a
minimally
viable
change
until
we
get
to
something
that's
really
truly
lovable
by
our
customers
and
then,
of
course,
it
of
course
delivers
value
more
quickly,
as
we
just
talked
about.
B
So
all
of
these
benefits
kind
of
work
together
to
you
know,
make
ci
cd,
something
that
is
really
in
you
know,
leading
the
industry
and
git
life
has
a
great
solution
that
is
easy
to
use
that
we'll
go
through
today,
all
right,
so
the
next
thing
I
wanted
to
kind
of
walk
you
through
was
the
kind
of
get
lab
recommended
process
for
these
kind
of
small
changes
now
keep
in
mind.
Github
is
very
flexible.
B
You
don't
have
to
use
this
exact
process,
but
it
does
kind
of
frame
some
of
the
things
we're
going
to
talk
about
later,
so
it's
good
to
understand
it
and,
if
you're
doing
a
different
process
today,
you
can
actually
start
with
that
process
today
and
then
make
small
changes
to
your
process
to
to
approach
this.
If
you
think
this
would
work
for
your
team,
you
know
long
term.
So
if
you
can
imagine
this
bottom
line
is
your
default
branch
of
code.
So
this
is
where
your
production
code
lives
and
with
gitlab.
B
What
we
recommend
is
you
start
with
an
issue
and
within
within
that
issue,
which
could
be
a
user
story?
A
feature
request:
a
bug
report,
whatever
you're
discussing
with
your
teammates
and
your,
maybe
even
your
stakeholders
and
your
customers.
What
the
change
is
going
to
be.
What's
it
going
to
look
like
what's
the
priority,
how
difficult
is
it
going
to
be?
When
should
it
be
done,
and
all
of
those
discussions
happen
within
the
issue?
B
One
of
them
can
create
a
merge
request
and
when
you
create
the
merge
request,
it'll
automatically
when
you
create
it
from
the
issue,
it'll
automatically
create
this
feature
branch
for
you
and
and
put
you
on
that
feature
branch
and
we
actually
recommend
you
create
the
march
request
at
the
beginning
of
the
process
and
you're
going
to
see
why
here
in
a
moment
as
your
team
is
making
their
changes
on
the
feature
branch,
those
changes
are
isolated
from
your
production
or
default
branch,
and
that
means
if
there
is
some
kind
of
bug,
introduced
or
negative
impact.
B
It's
only
going
to
affect
the
folks
working
on
this
and
then,
when
those
commits
are
made
the
and
push
back
up
to
the
server
your
ci
pipeline
can
be
configured
and
by
default,
is
configured
to
run
automatically
and
give
you
the
feedback.
B
B
B
If
you
wanted
to
in
and
basically
give
your
team
the
ability
to
manual
test
the
ability
to
get
feedback
right
away
from
internally
and
so
on,
and
then
within
the
merge
request,
you
can
also
have
discussions.
You
can
actually
discuss
it.
The
changes
you
can
have
code
reviews,
there's
a
really
neat
code
review,
feature
we're
not
going
to
go
into
today,
but
and
there's
also.
B
You
can
also
have
your
security
team
review
the
security
results
and
give
you
feedback
on
which
changes
need
to
be
made
now
which
can
be
pushed
into
issues
and
so
on,
and
then,
ultimately,
you
can
set
up
an
approval
process
within
the
merge
request
that
allows
different
approval
rules
based
on
different
conditions,
as
well
as
static
rules.
Where
you
want
to
have
you
know
a
project
manager,
look
it
in
a
manager,
look
at
whatever
the
case
may
be
and
who
needs
how
many
approvals
you
need.
B
This
is
optional,
but
is
a
nice
gate
and
then
any
changes
can
reset
all
of
this
rerun
the
pipeline
and
even
reset
the
the
approvals
until
you're
really
happy
with
this
change.
When
everybody's
happy
with
it
your
pipeline
look
results,
look
great!
Your
test
results.
Look
great!
Your
scans
look
great
everyone's
happy
with
the
discussion
everyone's
approved
it.
You
can
then
merge
this
change
back
into
your
default
branch
with
confidence
and
your
deployment
pipelines
can
run
additional
security
scans
against
the
deployment.
B
You
could
just
start
by
the
build
and
then
add
unit
tests
and
then
add
tests
as
you
go
and
that's
a
very,
very
powerful
way
to
kind
of
get
started.
B
And
then,
ultimately,
you
can
push
out
to
the
different
environments.
You
can
use
gitlab
to
control
these
environments
or
you
can
just
do
this
within
the
jobs
that
you
define
we're
going
to
talk
all
about
that
here
in
a
moment,
so
you
can
push
out
to
review
environments,
staging
environments,
production,
it's
very
flexible
with
how
that
works
and
we're
going
to
go
into
that
a
little
bit
here
as
well
all
right.
So
let's
talk
about
what
this
actually
looks
like
in
in
git
lab.
B
So
the
first
thing
you
have
to
understand
is
that
we
have
a
thing
called
jobs
and
jobs
are
actually
what
run
and
perform
the
tasks
we
want
to
do
so.
If
you're
whatever's
building
your
code,
that's
a
job.
Each
individual
test
may
be
a
separate
job
or
you
may
pull
several
tests
together
into
a
single
job
and
then
each
deployment
is
going
to
be
job,
so
in
the
graph
you
see
below,
which
is
what
this
looks
like
in
gitlab,
each
of
these
ovals
represent
individual
jobs.
B
We
also
have
stages,
so
stages
are
optional,
but
they
allow
you
to
group
jobs
together.
So
in
this
example,
we
have
a
build
stage
with
one
job,
a
test
stage
with
these
three
different
tests
and
so
on
by
default.
Jobs
within
a
stage
are
executed
in
parallel.
So
in
this
case,
obviously
the
the
build
state
stages
run
sequentially
by
default,
and
so
once
this
build
job
is
completed.
B
All
three
of
these
test
jobs
will
be
eligible
to
be
run,
and
if
you
have
runners,
runners
are
the
things
that
actually
execute
the
jobs
which
we're
going
to
talk
about
towards
the
end.
They
will.
If
you
have
enough,
if
you
have
runners
available,
all
three
of
these
jobs
will
run
simultaneously
and
then,
if
you
have
a
job
fail
in
a
given
stage,
then
by
default
it
will
prevent
the
rest
of
the
pipeline
from
executing
and
mark.
The
pipeline
has
failed,
but
you
can
mark
jobs
to
allow
failure.
B
So,
if
you're,
adding
a
new
job,
for
example-
and
you
just
want
to
see
how
it
runs,
but
you
don't
want
to
hold
the
rest
of
the
pipeline,
you
can
mark
it
as
a
allow
failure.
B
So
we've
talked
about
commits
when
you
push
code
to
your
repository
now,
keep
in
mind
that
when
you
do
a
commit
locally
on
your
local
machine
that
is
not
going
to
trigger
the
pipeline,
it's
only
when
the
gitlab
server
knows
about
that
change.
So
it's
only
when
you
push
code
to
the
the
gitlab
server
repository
it's
going
to
trigger
the
pipeline,
but
you
can
also
trigger
pipelines
manually
from
the
user
interface
within
git
lab.
B
B
You
can
also
have
pipelines
triggered
by
another
upstream
pipeline,
and
so,
if
you
have
like
a
series
of
projects
that
all
run
microservices,
you
could
have
an
upstream
pipeline
that
kicks
all
off
those
off
and
they
each
have
their
own
individual
pipeline.
We're
not
going
to
go
into
that
today,
but
we
do
cover
that
in
the
advanced
ci
cd
session
and
so
stay
tuned
for
upcoming
editions
of
that.
B
If
you
want
to
learn
more
about
that-
and
of
course
you
can
also
use
the
gitlab
api
to
launch
a
pipeline
and
there's
lots
of
options
there
as
well,
so
you
can
actually
have
it
triggered
from
another
system
or
you
could
build
your
own
to
use
the
api
to
to
do
that
all
right.
So
next
we're
going
to
talk
about
what
this
actually
looks
like
in
gitlab
and
how
you
are
going
to
set
everything
up.
B
So,
first
and
foremost,
the
thing
you
need
to
understand
is
everything
starts
with
a
special
file
that
goes
in
the
root
of
your
project,
called
dot.
Git
lab
dash,
ci
dot
yaml.
Now
yaml
is
yet
another
markup
language,
but
it
it's
fairly
standard
online
amongst
the
industry
and
it's
fairly
easy
to
learn
if
you've
never
worked
with
it
before
and
we're
actually
gonna
walk
through
and
build
out
a
yaml
over
the
next
three
slot,
a
few
slides
and
you
will
get
a
copy
of
the
slides
as
well
as
the
recording.
B
So
you
can
kind
of
follow
along
with
this
within
your
own.
You
can
create
a
project
in
your
own
instance
and
kind
of
follow
along
and
start
these
on
your
own,
but
for
today,
just
kind
of
follow
along
and
and
we'll
go
through
the
process.
B
So,
let's
just
point
out
a
couple
of
things
that
we
talked
about
already.
So
there
is
a
section
to
define
the
stages.
This
is
the
only
section
within
the
ci
yml
that,
where
the
order
matters
so
in
this
case
the
stages
are
going
to
execute,
build
and
then
deploy
it
doesn't
matter
where
the
jobs
or
get
to
the
jobs
in
a
minute.
The
jobs
can
be
in
any
order
because
jobs
happen
in
parallel
within
a
stage.
The
only
thing
that
really
matters
is
the
stage
order.
B
B
It's
going
to
be
part
of
the
stage,
build
it's
going
to
run
a
script
and
we'll
talk
about
this
in
a
minute,
some
more
details
about
the
script,
but
the
script
is
basically
whatever
you
would
have
done
to
execute
the
build
if
you're
doing
it
manually
and
then
in
this
case,
there's
some
only
and
we
also
have
we
have
only
an
accept
which
is
a
good
way
to
start,
but
we
also
have
a
full
rules.
Engine
that
is
available.
B
You
can't
mix
rules
with
only
but
you
you
know
this
is
basically
saying
only
if
it's
on
the
main
branch
are
we
going
to
run
this
and
then
finally,
we
have
a
deployed
job
which
is
in
the
deploy
stage.
It
runs
a
different
script
and
because
it's
deploying
we
tell
it
some
information
about
the
environment
that
it's
going
to
go
to.
So
this
is
the
server.
This
could
be
a
static
server.
It
could
be
a
kubernetes
cluster,
there's
a
lot
of
different
options.
B
You
can
also
declare
variables
you
can
also
have
variables
that
are
used
by
all
available
to
all
the
jobs
as
well
as
variables
that
are
only
used
by
this
one
job
and
so
on.
So
we're
going
to
go
through
this
as
we
build
up
the
examples.
B
So,
as
I
mentioned,
there's
a
number
of
keywords
that
you've
already
seen
and
there's
a
bunch
that
we're
going
to
cover
today,
but
there's
a
bunch
more
that
we're
not
going
to
have
time
to
get
through
today.
So
there
is
a
great
resource
here,
which
this
is
a
link
to
our
docs
page.
That
has
all
of
the
available
keywords
explains
them,
gives
you
examples
and
lets
you
go
through
a
lot
of
it
and
we
cover
you.
B
You
cover
more
in
the
advanced
icd
session,
so
definitely
check
this
out
when
you
get
a
copy
of
the
slides.
B
B
I
actually
recommend
that
you
always
declare
the
stages
explicitly,
especially
when
you're
first
getting
started,
because
it's
a
lot
easier
to
understand
and
follow
what's
happening,
and
so,
but
you
there
are
some
shortcuts
you
can
take,
because
there
is
available
a
build
stage,
a
test
stage,
a
review
stage
and
a
deploy
stage
by
default.
B
Now
you
can
you
can
if
you
need
to
do
your
build
in
two
steps
and
then
you'd
have
it
in
sequence.
You
can
create
a
build
one
and
a
bill,
two
same
thing
with
tests
and
so
on.
So
you
really.
This
is
fully
configurable,
but
this
is
kind
of
the
the
base
for
default
stages.
B
So
you
have
a
couple
different
examples
here.
So
the
the
green
text
here
is
the
name
of
the
job.
The
orange
ones
are
the
keywords,
and
then
the
white
here
is
the
words
that
are
the
parameters,
we're
passing.
You
know
for
those.
So,
for
example,
in
this
build
code
one
it
is
actually
going
to
run
a
buildit.sh
script
and
this
for
for
windows.
Folks,
this
could
be
a
batch
file.
B
It
doesn't
have
to
be
an
sh
script,
but
it
could
be-
and
in
this
case-
because
there's
no
pathing-
it's
assuming
that
this-
this
is
obviously
in
the
root
of
your
project.
So
if
you
have
a
build
it
dot
sh
in
the
root
of
your
project,
you
will
basically
execute
that
and
that
way
the
script
is
defined
in
a
file.
It's
really
nice
and
simple.
You
can
make
changes
to
the
file
that
will
trigger
a
new
pipeline
and
you
can
see
what
happens
and
test
it
and
so
on.
B
You
can
also
have
this
build
other
code
as
an
example
of
ones
where
you're
providing
a
full
path,
because
you
have
the
script
in
a
subdirectory
in
your
project
so
again,
starting
with
the
root
it's
in
this
directory
structure
and
then
the
the
script
is
down
here,
but
you
don't
have
to
you.
If
you
have
like
a
very
simple
script,
you
can
actually
do
it
in
line
within
the
script
keyword.
B
B
As
long
as
they're
consistent
you'll
be
fine
and
then,
ultimately,
you
can
also
call
scripts
this
way
as
well,
and
you
can
mix
and
match
these.
So
a
lot
of
different
examples
on
how
to
incorporate
different
ways
of
defining
scripts
within
your
jobs.
B
Okay,
great,
so,
let's
take
a
look
at
this
kind
of
emotions,
so
here
is
an
example
of
a
test
job
now
notice
that
there's
no
stage
defined
for
this.
That's
weird!
Well,
if
you
remember,
because
build
deploy,
review
and
are
the
four
default
stages
remember
that
if,
if
your
job
is
also
named
one
of
those
four
review
keywords,
gitlab
just
assumes
you
know
what
this
is
going
to
go
in
the
stage
test.
Now,
in
this
case,
I
because
my
job
name
is
staging
it
has
to
be.
B
I
have
to
tell
which
stage
it's
going
to
be.
However,
in
this
case
right
here,
I
would
actually
recommend
that
you
also
just
use
stage
colon
test,
because
then
it's
explicit
and
you
understand-
what's
happening
but
again,
here's
an
example
of
a
script
with
multi-line
and
here's
a
different
example,
and
so
on.
So
you
can
see
some
different
examples.
You
can
also
tell
here
that
remember
the
order
that
you
declare
jobs
is
irrelevant.
B
It's
going
to
execute
them
based
on
the
stage
definition,
so
this
is
just
a
little
snippet
with
some
basic
options
for
the
only
here
we
saw
this
example
before
where
it's
only
going
to
fire
on
the
the
if
a
change
was
made
to
main
in
this
case.
It's
all
this.
This
job
is
only
going
to
be
included
in
the
pipeline.
B
If
the
code
was
a
git
tag
was
applied
to
the
code,
there's
a
lot
of
data
that
are
available
even
more
with
the
rules
engine
that
we've
added,
and
I
definitely
encourage
you
to
take
a
look
at
the
rules
and
we'll
show
you
an
example
of
that
later,
all
right.
So,
let's
start
building
out
our
pipeline,
there's
a
few
things
that
you
can
do
outside
of
jobs
within
your
pipeline
definition.
One
of
those
is,
if
you're
using
containers,
you
can
tell
it
what
the
default
image
is
for
all
jobs.
B
You
can
use
a
public
image
which,
if
you
don't
provide
a
pathing,
it's
going
to
assume
that
this
is
going
to
be
pulled
from
docker
hub.
So
that
means
that
your
instance
has
to
be
able
to.
You
know
you're
not
blocking
access
to
docker
hub
if
you
are
you're
going
to
need
to
provide
a
full
path
like
we
do
here.
So
if
you
have
a
container
stored
in
the
gitlab
registry,
you
can
provide
a
path
to
that.
B
It,
of
course,
can
be
in
any
external
registry
that
you
have
access
to
and
you
just
need
to
provide
the
full
url
and
path
to
the
image
name
and
then
the
the
version.
So
you
you
have
a
couple
different
options
here
you
could
do,
and
in
this
case,
what
we're
going
to
do
is
we're
going
to
build
out
our
ci
by
adding
in
the
image
and
we're
going
to
use
this
image,
which
is
just
a
fake
one.
B
Obviously,
but
just
to
give
you
an
example,
the
next
thing
you
might
need
to
do
is
if
you're,
oh,
by
the
way,
if
you're
not
using
containers,
you
don't
need
to
do
the
image
at
all,
obviously,
because
that's
really
only
used
for
containers
and
kubernetes
type
jobs,
our
pipelines.
B
B
So
your
main
job
will
run
in
this
main
container,
but
anything
you
declare
in
services
will
be
available
and
to
to
that
main
container
as
a
separate
container,
and
then
you
can
also
declare
variables
so
the
variables
that
are
declared
outside
of
a
job
using
the
variables
keyword.
These
variables
will
be
available
to
every
single
job,
and
so
you
can
use
them
in
your
scripts
and
and
so
on.
You
can
also
put
these
in
inside
jobs
and
they
will
actually
override
these.
B
If
you
declare
the
same
thing
so
these
will
be
available
for
for
all
jobs.
So
here
we
have
we've
added
the
services
because
we
need
postgres
and
then
we've
added
a
global
variable,
this
basically
a
global
variable
for
your
ci
pipeline.
B
Okay.
So
here's
what
we
look,
here's
what
it
looks
like
so
far.
We
have
our
image
our
services,
our
variables,
we've
declared
our
three
stages,
even
though
we
didn't
have
to
and
now
we're
going
to
add
our
first
job,
so
we're
going
to
add
a
job.
That's
called
deploy
dash
code
in
the
stage
deploy
and
it's
going
to
run
a
single
command,
and
you
can
see
here
this
is
actually
using
the
method.
B
I
love,
even
if
it's
a
single
command,
because
this
is
set
up
to
allow
you
to
add
additional
ones
very
easily
down
the
road.
So
even
if
you're,
starting
with
a
single
command,
if
you're
doing
something
like
maven
or
another
system,
where
you
could
do
everything
in
one
command,
then
you
you
can
do
it.
This
way
is
what
we
recommend.
So
now
we
have
a
job
definition
built
in
now,
so
we
we
now
a
pipeline
with
one
single
job.
B
In
this
case,
this
is
showing
you
a
cube,
kubernetes
cluster.
You
don't
have
to
use
this.
You
saw
an
example
earlier
where
it's
a
static
server
and
that's
perfectly
fine-
you
can
do
that.
Gitlab
can
still
deploy
to
it.
But
what
gitlab
can't
do,
if
you
point
gitlab
to
a
cluster,
then
gitlab
can
spin
up
additional
pods
and
do
other
things
and
allow
you
to
monitor
and
interact
with
that
dynamically
static
environment.
You
have
less
options
there.
B
You
can
also
specify,
when
the
when
here
is,
is
going
to
be
when
this
environment
is
going
to
be
used
and
when
triggers
jobs
and
stages
manually.
So
in
this
case,
it's
going
to
give
you
a
manual
play
button
for
the
for
this
job,
so
that
the
pipeline
will
pause
and
wait
for
someone
with
permissions
to
click
that
I'll
show
you
an
example
of
what
that
looks
like
in
the
pipeline
graph
in
a
minute.
B
B
It's
only
going
to
run
it
for
a
change
made
to
a
branch,
a
commit
made
to
a
branch,
except
if
it's
the
main
branch
and
then
I'm
going
to
define
my
environment
of
where
this
deployment's
going
to
get
pushed
it's
going
to
be
called
the
review
environment,
and
it's
going
to
be
pointing
to
this
review
cluster.
B
So
only
is
gonna
only
and
accept
our
very,
very
simple
ways
and
if
you've
been
using
git
left
ci-
and
you
have
these-
you
know
you
can
continue
to
use
them.
We're
not
adding
functionality
and
totally
and
accept
everything.
B
New
is
happening
within
rules,
and
rules
is
much
improved
over
only
except
much
more
powerful
and
if
you're,
just
starting
out,
you
could
use
only
an
accept,
but
you
you
definitely
can
take
a
look
at
rules
just
to
show
you
what
this
looks
like
if
we
looked
at
this
exact
same
job
with
rules.
B
This
is
what
it
looks
like
you
create
use
the
rules,
keyword
to
create
a
rules
block,
and
this
is
basically
saying
if,
if
the
branch
name
is
name
is
main
that
the
commit
was
made
to
then
then
do
not
include
this
job.
Otherwise,
always
include
this
job.
B
We
go
into
rules
in
a
lot
more
detail
and
examples
in
the
advanced
ci
sessions
of
this
so
definitely
keep
an
eye
out
for
an
upcoming
session
for
that.
B
Okay.
So,
let's
now
talk
about
before
and
after
scripts
before
and
after
scripts,
allow
you
to
define
a
script
that
will
execute
before
or
after
a
job.
The
before
script
is
pretty
simple.
You
can
define
this
outside
of
of
a
job,
so
it
applies
to
all
jobs.
B
You
can
also
define
it
inside
a
job
if
you
wanted
to,
but
basically
the
before
script
just
gets
concatenated
on
to
the
top
of
your
main
script.
So
it's
something
that
will
execute
before
your
main
script
and
it's
as
if
you
still
just
saving
you
from
typing
this
into
each
script
and
allowing
you
to
kind
of
declare
this
once
outside
of
a
job
and
and
then
it
gets
executed
at
the
beginning,
and
then
your
main
script
gets
like
immediately
after.
So
it's
almost
like
you're
just
copying
and
pasting
this.
B
On
top
of
your
main
script,
the
after
script
works
a
little
differently.
So
what
happens
with
the
after
script?
Is
it
will
run
at
the
end
of
each
job?
Even
if
there
is
a
failure?
This
is
very,
very
important.
So
if
you
run
into
a
failure,
it
will
cause
the
the
rest
of
that
script
to
to
get
aborted
and
but
then
the
after
script
will
run
at
the
end.
B
One
important
thing
to
remember
is:
if
you
manually
stop
a
job
through
the
gitlab
ui.
It
will
not
run
the
after
script,
because
you've
told
that
job
hey
just
stop
what
you're
doing
I
don't
care,
so
that's
important,
so
after
scripts
will
run
even
if
a
failure,
but
not
when
you've
intervened
manually.
B
So
now,
you're,
probably
thinking
to
yourself.
Okay,
we've
got
all
these
different
jobs.
I've
got
to
build
job.
How
do
I
get
what
was
made
in
the
build
job
over
to
my
test
job,
or
do
I
just
have
to
redo
the
build
job?
And
if
that's
the
case,
then
why
did
I
have
a
build
job
in
the
first
place?
Well,
you
can
pass
stuff
between
jobs
and
stages,
using
cash
or
artifacts.
B
The
main
difference
between
cash
and
artifacts
is
cash
only
lives
for
the
lifetime
of
the
pipeline.
Once
the
pipeline
is
completed,
cash
is
no
longer
available,
but
anything
you
declare
to
be
stored
will
be
passed
between
jobs
using
the
the
cash
artifacts,
on
the
other
hand,
will
get
saved
and
uploaded
to
the
gitlab
server
and
can
be
accessed
through
the
gitlab
ui.
B
There
are
ways
you
can
control
when
those
artifacts
get
purged
and
under
what
conditions
and
such,
but
we're
not
going
to
go
into
that
today.
So
with
each
of
these,
you
can
define
what
paths
you
want
to
do.
So
this
is
basically
saying
everything
in
the
binary
directory
and
everything
with
a
dot
config.
B
This
one
is
just
saying
everything
in
this
bin
target
directory.
You
can
also
have
with
artifacts.
You
can
declare
when
you
want
this
to
be
stored,
so
this
went
on.
Success
means
hey
only
store
the
artifacts.
B
If
the
job
succeeded,
if
you
leave
that
off
the
any
artifacts
that
were
created
will
get
uploaded,
even
if
the
job
fails
so
if
like,
if
they
are,
if
the
job's
going
to
create
two
executables
and
the
first
one
succeeds,
the
second
one
fails,
it
will
store
the
first
one
in
this
case
it
would
store
neither
because
the
job
if,
if
it
failed
on
the
second
step,
the
entire
job
fails.
So
that's
something
to
keep
in
mind,
but
you
can
do
wild
cards
and
store
entire
things
in
directories.
B
There's
even
advanced
things
you
can
do
with
accepts
and
and
and
so
on,
but
we're
not
going
to
go
into
that
because
today
is
just
kind
of
the
basics
intro
session,
all
right.
So
here's
where
we
are
looking
right
now,
so
everything
in
gray
is
the
stuff
we
already
covered
and
we've
added
in
a
cache
so
that
anything
that's
get
generated
into
the
binary
directory.
Will
get
past
passed
to
subsequent
jobs
in
stage
in
subsequent
stages?
B
So
now,
what
we're
going
to
do
is
we're
going
to
add
a
add,
a
job,
a
new
job,
so
we're
going
to
have
more
than
one
job
right
now.
We
only
have
one
job
we've
added
all
of
this
stuff,
but
we
still
only
have
one
job
that's
going
to
get
executed,
so
we're
going
to
have
a
second
job.
This
is
called
the
build
its
job.
It's
going
to
be
in
the
build
stage.
B
It's
going
to
run
this
script
again,
it's
only
going
to
run
if
a
change
was
made
to
the
main
branch
and
then
on
the
artifacts.
I
want
to
store
the
artifacts
so
here
this
cache,
because
it's
outside
of
a
job
is
applying
to
all
jobs,
but
the
artifacts
are
going
to
because
I've
declared
it
here
within
this
job.
I
could
have
declared
it
outside
of
the
job,
but
in
this
case
I've
declared
it
just
for
this
one
job.
It's
going
to
store
these
artifacts
anything
that
was
created
in
the
bin
target
directory.
B
So
what
that
means
is
this
job.
Anything
that's
created
by
this
job
will
get
stored
and
be
available
for
others
to
that.
Have
access
to
the
project
to
download
at
a
later
time,
whereas
anything
put
in
the
binary
will
simply
get
passed,
but
subsequent
jobs
in
subsequent
stages
will
have
access
to
everything
in
the
binary
folder,
as
well
as
everything
in
the
bin
target
folder
directory.
Sorry.
B
All
right,
so
there
is
the
next
thing
I
want
to
cover
is
ci
tags,
so
ci
tags
are
a
way
to
basically
force
your
jobs
to
be
run
by
a
specific
runner,
we're
talking
about
runners
in
a
moment,
but
because
they
are
defined
in
the
job
they
I
wanted
to
mention
them
now,
since
we're
going
through
the
job
definition,
do
not
confuse
these
with
git
tags.
These
are
different.
B
Basically,
what
this
is
saying
is
that
this
job
needs
to
be
run
by
a
runner.
That
is
also
tagged
with
these
two
tags,
so
any
any
runner
that
is
also
tagged
with
those
two
tags
is
eligible,
even
if
that
runner
has
additional
tags
on
it.
B
It's
basically
saying
that
this
has
to
be
run,
so
you
can
use
this
to
force
jobs,
to
run
on
a
specific
runner,
because
they're
going
to
be
high,
compute
or
maybe
they're,
they
require
a
specific
resource
like
mac,
os
or
ios
resources
that
are
on
that,
the
machine
that
that
runner
is
on
there's
a
lot
of
different
options
for
this.
B
B
All
right
and
we're
moving
into
the
runner
section,
and
then
we
will
have
some
time
for
q,
a
in
the
last
10
minutes
or
so
so
coming
up
soon,
I
will
go
through
any
questions
that
haven't
been
answered
already
by
the
team.
B
Okay,
great
so
runners,
as
I
mentioned
before,
the
the
core
of
gitlab
ci,
is
the
definitions
of
all
of
your
stages
and
jobs
and
variables,
and
all
that
good
stuff
in
your
get
lab
ci
email
that
we
just
went
through.
B
But,
as
I
mentioned
before,
runners
are
what
make
this
happen
and
runners
are,
are
really
the
thing
that
are
executing
the
jobs
and
they're
just
a
lightweight
agent
that
can
run
on
pretty
much
any
operating
system
that
actually
execute
the
jobs.
So
how
does
this
actually
work?
So
the
gitlab
runner
can
be
installed
anywhere
that
can
use
go,
which
includes
linux,
mac,
windows
and
so
on,
and
the
gitlab
runner
can
pretty
much
test
any
programming
language
and
so
the
way
this
works
is
you
have
your
gitlab
server.
B
We
do
not
recommend
installing
runners
on
the
gitlab
server,
as
there
may
be
a
competition
for
resources
that
we
want
to
avoid,
and
then
you
can
have
as
many
different
runner
servers,
but
remember
that
server
is
kind
of
a
loose
term.
So
you
can
run
runners
on
a
desktop.
You
can
run
it
other
and
we're
going
to
talk
about
other
places.
You
can
have
them
running
in
kubernetes
and
and
or
docker
machine.
B
There's
a
lot
of
different
options
for
how
you
can
have
runners
and
you
can
have
a
mix
of
them
that
are
available
to
run
all
of
these
different
jobs
and
you
can
install
the
runner
on
your
own
laptop
and
and
force
jobs
onto
that
using
those
tags
we
talked
about
earlier
and
so
on.
So
and
what
happens
here
is
the
runners?
B
Do
a
simple
https
web
service
call
back
into
the
gitlab
server
and
they
basically
say
hey
I'm
here:
do
you
have
anything
for
me
and
if
the
gitlab
server
it's
like,
oh
yeah,
I
do
have
a
job
that
you
could
do.
It
will
reply
back
so
the
server
never
contacts,
the
runner
runners
are
continuously
on
a
periodically.
I
should
say
pinging
the
server
and
asking
for
things
to
do
and
then,
if
there's
nothing.
B
B
B
So
the
idea
behind
shared
and
specific
runners,
shared
runners,
are
generally
set
up
by
the
gitlab
admin
and
are
available
to
all
projects.
Now
projects
can
pick
whether
they're
going
to
allow
the
the
shared
runners
to
be
used,
but
these
are
basically
generic
runners
that
can
run
generic
jobs
and
the
gitlab
admin
wants
to
make
these
available.
Just
to
let
people
get
started
with
ci,
then,
as
teams
figure
out,
you
know
what
I've
got
a
couple
specialized
jobs
and
then
the
shared
runner
pool
they're
all
pretty
much
the
same.
B
They
don't.
Let
me
do
specialized
things
like
running
on
mac
os
or
if
I've
got
a
a
really
complex
job
that
needs
high
compute
resources.
The
shared
runners
really
aren't
kill
you
know
doing
it.
For
me,
I
need
something
more
powerful,
so
I'm
going
to
create
specific
runners
and
and
those
specific
runners
can
be
tied
to
one
or
more
projects
or
groups.
They
can
be
created
by
anybody
who
has
a
maintainer
access
to
those
groups
or
runners,
and
it's
in
a
pool
just
for
those
projects
or
groups.
B
As
I
mentioned
before,
you
can
have
tagged
jobs,
and
thus
you
can
have
tag
runners
if
you
have
untagged
runners,
those
are
available
to
run
anything.
That
is
not
tagged.
So
if
you
don't
have
any
tags
in
your
job
definition,
an
untagged
runner
will
be
able
to
run
that,
generally
speaking,
your
pool
of
shared
runners
are
also
traditionally
going
to
be
untagged,
but
you
could
have
tag
ones
there
too,
and
then.
The
other
thing
here
is
the
other
example
here
is
that
this
one
says
hey.
B
This
has
got
to
be
running
the
windows,
runner
and
I've
tagged
this
runner
as
windows.
Remember
that
these
words
you
use
here
are
just
arbitrary.
They
can
be
whatever
you
want
as
long
as
they
match.
This
job
will
be
eligible
to
be
run,
but
on
this
particular
runner
also
do
keep
in
mind.
Runners
can
have
multiple
tags,
so,
for
example,
in
that
previous
example,
the
runner
was
tagged
or
the
job
was
looking
for
mac
os
and
ios.
B
So
you
could
have
a
runner
that
is
tagged
for
mac,
os
and
ios,
but
a
job
that
only
requires
mac
os
will
be
able
to
run
on
that
because,
as
long
as
that,
runner
can
meet
the
minimum
requirements
of
the
job,
it
will
allow
it
to
run
on
there.
It
doesn't
matter
if
the
runner
has
additional
tax,
but
if
you
have
additional
tags
in
the
job
that
aren't
in
the
runner,
then
that
runner
will
not
be
eligible.
B
B
There
are
some
additional
runner
options.
So
when
you
register
your
runner
install
and
register
it
back
with
the
server
or
with
the
group
or
with
the
project,
you
can
also
then,
once
it's
registered,
you
can
go
in
and
configure
these.
You
can
determine
you
know,
tell
gitlab
hey
this,
this
runner
is
active,
is
it
protected?
Is
it
allowed
to
run
on
tag
jobs
because
remember
an
untagged
job
will
be
eligible
to
run
on
any
runner,
even
tag
runners.
B
B
And
then
there
are
different
when
you
register
a
runner
or
install
set
up
the
runner,
you
have
to
tell
it
what
kind
of
how
it's
going
to
execute
it.
So
the
most
common
are
shell
executors,
which
basically
are
just
going
to
run
it
as
if
you
were
physically
on
the
machine,
whether
it
be
you
know,
linux
or
windows,
or
something
like
if
you're
just
typing
into
the
command
prompt.
B
But
we
also
do
have
docker
runners.
We
have
docker
machine
runners
and
kubernetes
docker
machine
and
kubernetes
are
both
great
options
for
auto
scaling
runners.
So
you
can,
you
know,
spin
up
additional
ones
as
needed
and
spin
them
down,
but
we
also
do
have
some
less
common
ones.
Ssh
is
is
available,
it's
similar
to
the
shell,
but
it
doesn't
it
actually
like
sshs
into
the
target
machine.
B
So
if
you
don't
want
to
install
the
runner
on
the
target
machine,
you
use
this
ssh,
but
there
are
some
limitations
and
then
we
also
do
have
a
virtual
box
and
parallels
available
as
well.
There's
there's
more
on
our
page.
If
you
want
to
see
those
all
right
so
now
we
are
going
to
kick
it
back
over
to
taylor
and
I
think
he
has
something
he'd
like
to
go
over
and
then
we'll
go
into
questions.
A
Yeah
thanks
kevin.
I
am
going
to
open
up
a
feedback
poll.
I
just
did
that
we'd
love
to
to
hear
from
from
you
all
just
a
couple
of
of
quick
questions
there
about
today's
session
and
and
from
there
we
will.
We
will
go
into
q,
a
kevin.
I've
got
a
couple
that
have
that
have
come
through
and
you
can.
A
You
can
take
a
look
in
the
q
a
there
as
well,
but
the
first
one
that
I
saw
come
through
is
what
what
is
the
best
way
to
get
started
with
ci
cd.
B
Yeah
great
great
question
so
yeah.
What
I
would
say
is
if
you're
brand
new
to
ci
or
maybe
you're
coming
from
another
search
system,
or
maybe
you
you're
just
doing
stuff
manually
today,
you
don't
have
to
get
to
a
complete
solution
on
day,
one
right,
just
just
maybe
start
by
creating
a
single
job
in
a
single
stage
that
just
does
the
build,
and
then
you
grab
the
build
results
off
of
that
server
manually
and
do
the
rest
of
your
process.
And
then
I
mean
next
sprint.
B
Then,
before
you
know
it
you're
gonna
have
you
know:
20
30,
40
jobs
that
are
doing
automatically
testing
every
aspect
of
your
application
and
you
did
it
organically.
You
did
it
through
your
normal
process
and
it
wasn't
this
huge
heavy
lift.
So
you
can
do
it
incrementally
and
kind
of
slowly
migrate
from
wherever
your
current
solution
is
into
where
you
want
to
be
where
everything
is
automated.
Everything
is
happening
with
every
commit
you're
getting
feedback
right
away.
So,
that's
that's
how
I
would
recommend
you
start.
B
And
just
looking
at
the
q
and
a
I
see
a
couple
of
questions,
so,
yes,
the
recording
will
be.
You
will
get
an
email
with
the
recording,
even
if
you
have
colleagues
that
registered
for
the
event
but
maybe
couldn't
attend,
I
believe
taylor
wright.
They
will
get
the
recording
as
well
correct
and
you'll
also
get
a
copy
of
the
slides.
B
So
you
can
share
those
with
your
colleagues.
You
can
even
reuse
the
slides
if
you
wish
to
for
your
own
internal
purposes,
they're
they're
covered
by
the
license
agreement,
so
you
can
reuse
them
and
customize
them
for
internal
training
purposes.
If
you
want.
B
Couple
other
questions:
let's
see,
I
believe
the
runners
pull
the
source
code
to
run
the
build.
Is
this
true?
Yes,
yes,
I
I
forgot
to
mention
that
so
every
job
will
actually
pull
down
the
the
code
repository.
There
are
some
options
which
we
didn't
go
into
today
to
allow
you
to
control
how
much
it
gets
pulled
down
if
you
don't
need
it
all,
but
but
yes,
every
job
will
pull
down
the
the
the
repo
and
that's
how
you
have
access
like
to
those
script
files
that
I
mentioned
earlier.
B
Are
there
plans
for
git
lab
to
have
a
built-in
secrets
manager?
That
is
a
great
question.
I
don't
know
if
one
of
my
colleagues
knows
the
answers
to
that.
I
do
know
that
we
have
a
great
integration
with
hashicorp
and
there
is
a
a
free
version
for
hashicore
vault
that
a
lot
of
my
customers
use.
B
So
I
know
that's
a
great
option
and
I
think
I
don't
know
if
we
have
plans
on
our
roadmap
right
now
to
to
try
and
replace
that,
because
we
we
think
that
that
solution
is
really
well
done.
So
I
don't
think
so.
B
What
is
the
best
learning
resource
to
learn?
Yaml
great
question,
so
what
I
would
say
is
start
with
a
link
on
our
website
and
it
gives
you
lots
of
different
examples.
There's
also,
if
you
go
to
gitlab.com,
learn,
there's
a
lot
of
great
resources
and
videos
that
are
available
there,
as
well
as
our
youtube
channel.
B
Thegitlab.Com
is
nice
because
it
groups
them
together
by
use
case.
So
you
can
go
straight
to
ci
and
kind
of
look
at
it's
a
mix
of
resources,
videos
and
other
media,
and
then
the
other
thing
I
forgot
to
mention,
which
I
probably
should
have
was.
We
now
have
built
in
a
gitlab
ci
editor.
So
when
you're
on
the
main
in
in
the
ui,
you
can
bring
up
the
editor
page
and
you
can
actually
make
changes
directly.
B
There
view
the
pipeline
how
it's
going
to
change,
and
that
is
a
very
valuable
resource,
because
it
does
a
lint
test,
a
verification
test
dynamically
as
you're
typing,
to
tell
you
what's
wrong
with
the
animal
and
that's
a
great
way
to
kind
of
get
started,
and
it's
a
neat.
Little
editor,
that's
built
into
the
gitlab
ui.
So
it's
under
ci
cd,
editor
pipeline
editor.
B
See
the
next
question
we
have
is:
do
we
have
git
lab
recommended
best
practices
for
ci,
cd
and
and
runners
yeah?
I
think
we
hit
a
lot
of
those
today.
I
don't
know
feel
free
to
put
another
question.
If
you
have
like
more
specifics,
but
basically
again,
I
would,
I
would
start
just
start
simple.
You
can
start
by
having
a
single
runner
in
a
single
job
and
then
just
build
out
from
there.
B
I
would
definitely
highly
encourage
you
to
set
up
a
pooled
set
of
runners.
It's
really
easy
to
do
that.
You
can
start
with
individual
runners
and
then
work
your
way
up
to
like
the
auto
scaling
with
docker
machine
or
kubernetes,
as
you
need
it
and,
and
then
just
just
start
small
and
then
build
your
way
up
is
definitely
what
I
would
recommend.
B
Let's
see
another
question
I
have
is
aws
azure
google
cloud
which
one
to
choose
for
kubernetes
for
kubernetes
to
run
gitlab
runner
well,
git
lab.
I
should
have
mentioned
this
one
as
well.
Good
git
lab
is
cloud
agnostic,
so
we
actually
play
well
with
all
of
those
cloud
providers
and-
and
we
support
a
lot
of
different
flavors
of
kubernetes,
so
definitely
check
our
docs
for
what
the
latest
ones
are,
but
you
can
really
use
any
of
those.
B
So
what
I
would
recommend
is,
is
you
use
the
ones
you're
most
familiar
with
to
start,
but,
and
you
don't
even
have
to
lock
into
one
of
those
right
like
you
could
actually
set
it
up
so
that
if
you
have
different
teams
that
are
using
different
clouds,
they
could
use
different
that
have
runners
running
on
kubernetes
clusters
in
those
different
clouds
for
all
from
the
same
instance,
so
you're
not
locked
into
one.
B
Let's
see,
can
you
please
share
the
links
which
mentioned
in
the
session
for
the
practice
and
study
purposes.
Yeah,
so
you'll
be
getting
a
copy
of
the
slides.
So
when
you
go
through
the
slides
I
I
have,
there
are
links
in
the
slides
that
are
in
there
and
those
links
take
her
to
our
docs
pages.
So
that's
that's
what
I
would
recommend.
B
How
do
I
reduce
the
size
of
the
gitlab
ci
gamble?
That
is
a
great
question
and
we
actually
have
a
great
feature
called
includes
include
that
allows
you
to
break
it
up
into
smaller
pieces
and
has
a
a
significant
advantage
because
it
allows
you
to
have
different
teams
maintain
those
individual
files.
So
if
you
have
one
team,
that's
maintaining
all
the
tests
and
one
that's
doing
all
the
unit
tests
and
one
that's
doing
the
ui
tests
and
so
on.
B
You
can
actually
create
them
as
separate
files
and
simply
use
the
include
keyword
to
pull
them
together.
There's
a
great
example
of
this
in
the
advanced
ci
cd
session,
which
I
think
we
have
one
of
those
coming
up
soon,
so
definitely
stay
tuned
and
sign
up
for
that
one.
I
would
highly
encourage
you
to
to
do
that,
but
if
not
go
to
our
website
and
look
at
includes-
and
you
can
even
look
at
git
labs
open
source,
you
can
actually
look
at
rci
yaml.
If
you
go
to
gitlab.comgitlab.org.
B
Gitlab
you
can
actually
go
into
the
repo
and
look
at
ours
and
basically
all
all
our
base
root
file
is,
is
a
series
of
includes
and
a
series
of
rules
and
there's
additional
rules
in
those
included
files,
and
so
it's
really
powerful
what
you
can
do
and-
and
you
can
have
hundreds
of
jobs
with
a
with
a
single
starting
file.
That's
only
like
40
or
50
lines,
you
don't
have
to
do
it
all
in
one.
B
B
So
I
would
just
build
as
you
go
and
don't
feel
like
you
have
to
learn
at
all
start
with
a
couple
of
simple
things
and
then
build
and
enhance.
As
you
go,
is
my
recommendation.
B
Let's
see
if
I
create
a
shared
runner
for
my
group,
will
other
people's
projects
outside
my
group
run
on
my
runner.
I
only
want
my
groups
projects
to
run
on
my
runner.
Yes,
so
if
you
create
a
shared
runner
for
your
group,
it
will
only
be
available
for
that
group
and
its
subgroups
and
projects,
so
other
people
that
are
in
external
groups
from
yours
will
not
have
access
to
it.
B
If
you
wanted
to
exclude
it
from
a
subgroup
that
becomes
a
little
bit
more
challenging,
you
might
want
to
create
it
at
a
different
level,
because
by
default
it
will
be
available
for
everything
below
it.
Then,
but
then
you
could
use
the
the
ci
tags
to
control
it,
and
you
could
mark
that
runner
as
do
not
take
untagged
jobs.
So
it
has
to
be
tagged
and
if
it
has
to
be
a
tag
job,
then
it
has
to
be
your
tag.
That's
using
it,
so
it
it's
not
perfect,
but
it
definitely
will
work.
B
B
Let's
see
there
are
many
reports
which
can
be
exposed
in
the
merge
request,
ui,
which
follow
certain
standard
conventions.
Is
there
any
plans
for
expanding
the
support
to
handle
different
formats,
making
the
ui
more
customizable
for
end
users?
Example
an
xml
or
json
containing
some
numbers:
how
to
only
show
a
specific
value
from
that
file
in
the
merge
request
without
having
the
end
user
to
open
the
file
in
the
merge
request.
B
You
know
that's
an
interesting
question.
I
have
not
run
across
that
one
before
I'm,
not
sure,
but
I
think
that
sounds
like
a
great
idea
to
create
an
issue
on
gitlab.com,
so
gitlab
is
very
transparent
with
the
way
we
do
business
and
we
love
things
like
this,
where
we
can
get
some
suggestions
from
customers.
Users,
even
even
you
know,
other
folks-
can
all
see
all
the
things
we're
working
on.
So
I
would
encourage
you
to
maybe
create
an
issue
with
what
you're
thinking
and
then
on
on
gitlab.com.
B
So
again,
skitlab.com
gitlab,
dashboard,
slash
gitlab.
You
can
create
an
issue
there
and
you
can
and
then
you
can
kind
of
lay
out
the
details
and
the
beauty
is
that
the
product
managers
that
are
working
on
that
area
will
then
start
asking
questions.
Other
users
will
chime
in
and
the
whole
community
will
be
working
on
a
solution
to
what
you
proposed.
So
that's
what
I
would
encourage.
B
B
If
you
don't,
then
I
would
just
use
cash.
However,
and
then
the
needs
piece
we
do
cover
that
in
the
advanced,
but
the
needs
allows
you
to
define
which
job
your
job
needs
the
artifacts
from
so,
for
example,
like
if
you're
doing
a
split
operating
system
build,
you
can
say,
the
mac
test.
Job
only
needs
the
artifacts
from
the
mac
build
job
and
the
linux
test.
Job
only
needs
stuff
from
the
linux,
build
job,
for
example.
B
So
I
would
definitely
take
a
look
at
both
of
those
but
but
yeah.
Basically,
if
you
need
access
later
to
those
files,
I
would
use
artifacts
and
if
you
don't
I'd,
use
cash.
B
All
right,
I
think
we
only
have
one
minute
left.
Is
there
a
way
to
access
a
service
instance
from
the
gitlab
ci
yaml?
I'm
not
sure.
If
I
understand
that
question
to
be
honest
with
you,
I
don't
know
if
anybody
else
on
does
and
wants
to
jump
in.
B
A
Yeah
thanks
everyone
for
joining.
Thank
you
kevin.
I
think
that
that
was
an
awesome
presentation
today
and
appreciate
the
engagement
from
everyone,
like
we
said,
we'll
be
sending
out
the
recording
and
deck
and
in
the
next
day
or
so
so
you
can
look
for
that,
and
otherwise
keep
your
eyes
out
for
for
future
sessions
like
this.