►
A
A
It
basically
uses
a
very
familiar
pattern
to
everyone
today.
We
only
have
three
stages:
test,
build
and
deploy,
and
what
we
want
to
do
is
we
want
to
use
some
environment
variables
inside
gitlab,
so
environment
variables
is
variables
only
available
to
jobs,
deploy
into
certain
environment,
but,
let's
say
for
some
reason:
we
want
to
use
environment
variable
not
only
for
deploying
jobs,
but
only
for
or
but
also
for
building
jobs
for
the
job
which,
let's
say,
builds
a
docker
image,
or
something
like
that.
So
all
these
three
jobs
are
very
similar.
A
Since
this
project
just
was
created,
the
pipeline
also
was
run
a
couple
of
minutes
ago
right.
So
the
first
stage
is
test
and
as
we
see,
our
staging
secret
is
empty
here
and
if
we
go
to
the
building
and
deploying
jobs,
I
will
just
go
to
only
to
build
job
to
demonstrate.
This
secret
station
is
present
and
it
looks
like
we
achieved
what
we
wanted
to.
A
So
why
is
that?
Basically,
every
time
you
specify
the
environment
keyboard
inside
the
gitlab
ti
gitlab
thinks
that
this
job
deploys
to
environment
and
yeah.
This
is
just
a
little
annoying
to
have
a
couple
jobs
here,
but
it
also
actually
breaks
the
workflow.
Gitlab
has
a
feature
which
allows
you
to
stop
old
deployment,
jobs
from
executing
and
overriding
your
newly
deployed
deployed
environment.
A
A
If
you
set
the
settings
right
and
in
this
particular
case,
if
you
held,
have
a
build
job,
it
can
actually
cancel
the
older
deployment
job
and
nothing
will
be
deployed
until
the
newer
deployment
will
run,
which
is
far
from
ideal
right
and
also,
if
you
have
multiple
jobs
and
accessing
environment
variables,
they
also
they
all
can
cancel
each
other
in
weird
ways.
So
obviously
you
don't
want
to
do.
A
A
So,
let's
look
at
the
testing
job,
as
you
see,
nothing
printed
still
bill.
Job
still
have
has
access
to
the
station
secret
as
well
as
sorry,
new,
second,
okay,
yeah
and
also
the
deployment
job
also
has
this
access
to
this
secret.
I
will
just
briefly
open
it
yeah.
So
let's
go
to
the
environment
one
more
time.