►
From YouTube: GitLab Demo variable inside variable
Description
Demo of the variable inside variable feature that is shipping on GitLab SaaS in 14.4.
Feature issue: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1809
A
Hello,
everyone
darren
eastman
here,
product
manager
for
gitlab
runner
in
today's
demo,
I'm
going
to
cover
a
feature
that
we
are
enabling
on
github.com
and
the
fortinet3
release.
It's
a
variable
and
signed
variable,
otherwise
known
as
a
nested
variables.
Expansion
feature
if
you'd
like
to
follow
along
in
a
bit
more
detail.
You
can
check
out
the
issue
in
our
github
runner
project.
It's
issue
number
1809
and
it's
titled
use
variable
inside
other
variable.
A
So
let's
go
ahead
and
pop
over
into
our
development
environment
and
take
a
look
at
how
things
are
set
up
before
we
actually
start
the
demo.
So
I've
got
my
project
ready
to
go
and
the
only
thing
I
want
to
call
your
attention
to
here
under
the
cic
settings
menu
and
then
expanding
the
variables
section
is
that
I
have
a
couple
of
variables
that
have
already
been
predefined.
A
The
other
variable
that
I
have
set
up
is
tied
to
the
keys,
equals
the
secret
underscore
var
and
the
values
minus
on
the
score
secret
underscore
variable.
This
is
a
masked
variable,
and
so,
when
we
get
into
the
actual
demo,
I
explain
what
we
expect
to
see
with
this
variable
handling
versus
the
other
variable
handling
terms
of
protected
variable.
A
So,
let's
go
ahead
and
pop
over
to
our
repository.
You
can
take
a
look,
how
things
are
set
up
and
just
to
set
the
stage
for
the
first
iteration
of
running
the
pipeline.
Currently
in
this
environment,
the
feature
flag
for
the
nested
variables
feature
is
not
enabled
so
what
you'll
be
seeing
here.
We
run
the
pipeline
for
the
first
time,
you'll
be
seeing
the
value
as
it
exists
prior
to
us,
enabling
that
future
flag.
A
So,
as
you
can
see,
this
is
a
pretty
straightforward
definition,
but
there
are
a
couple
of
things
here
that
I
want
to
call
out.
So,
under
the
variable
section,
we
have
three
variables
defined.
The
first
one
is
pretty
straightforward:
it's
just
var
three.
This
is
the
variable
name,
and
what
we're
doing
with
var
3
is
that
we're
appending
a
string
to
the
value
of
the
variable
name
equals
the
secret
underscore
file,
so
my
secret
underscore
variable
is
the
value
that
we
are
expecting
to
append
here
to
this
string.
A
Seeing
here
we're
saying
in
bound
one,
the
value
of
r
one
is
not
equals
to
protecting
far
and
variable
that
you
defined
in
the
ci
settings
menu,
and
it's
also
appending
the
ci
pipeline
9d
value
to
to
that.
So,
if
I
want
is
protected
file
dash
and
then
pending
the
ci
python
id
and
then
here
what
we're
going
to
do
in
a
script
evaluation
section.
A
Let's
just
basically
do
a
bunch
of
echo
statements
just
so
we
can
see
what
those
you
know
how
gitlab's
pipeline
handling
or
variable
handling
capability,
as
is
today,
handles
expanding
those
variables.
So
again,
to
recap:
I'm
going
to
execute
this
pipeline,
but
right
now,
for
this
first
run,
the
feature
is
not
enabled.
So,
let's
go
into
the
pipelines.
A
So
that
should
take
a
quick
second
to
kick
off
and
once
I'm
done,
it
should
be
complete
in
just
a
few
seconds
here
we
go
so
let's
have
a
look
at
the
output
and
I
have
a
screenshot
later
on.
We
can
compare
this
in
a
bit
more
detail,
but
you
can
see
here
in
the
output
of
the
screen
kind
of
what's
happening.
A
We
see,
however,
that
things
fall
apart
when
we
get
into
the
echo
statement
for
bar
2.,
so
try
and
study
the
appending
of
the
string
when
it
echoes
out
the
value
for
von
2,
but
then
it
gets
things
get
a
bit
confusing.
It
does
not
expand
today
the
protective
var
values,
nor
does
it
expand
the
ci
pipeline
id
values.
A
The
other
one
here
on
5.3
is
also
the
same.
What's
interesting
is
that
it
recognizes
today
that
that
variable
is
a
secret
variable,
so
it
returns
the
value
mask
which
is
kind
of
what
we
expect,
and
so,
when
this
is
one
of
the
reasons
just
kind
of
looking
at
this
example
with
these
sort
of
like
three
different
scenarios.
One
of
the
reasons
why
sometimes
understanding
how
variable
expansion
is
happening
in
github
today
could
sometimes
be
a
bit
interesting
if
you
will
okay.
A
So
what
I'm
going
to
do
now,
I'm
going
to
pop
over
to
my
other
console,
I'm
actually
going
to
enable
the
feature
flag
and,
let's
just
check
and
make
sure
that's
actually
enabled-
which
I
believe
is
because
we
did
see
a
return
value
of
true.
So
now
the
variable
inside
variable
feature
flag
is
enabled
on
the
gitlab
instance
that
I'm
using
for
this
test,
and
so
let's
rerun
that
pipeline
and
then
we'll
compare
the
values
and
better
results.
A
Okay,
we
can
just
see
here
right
away
that
the
output
is
different.
We
just
kind
of
quickly
jump
over
and
we
look
at
the
output
values
for
var2
to
make
this
even
a
bit
more
clear,
I'm
going
to
bring
up
another
screen
where
I
actually
have
a
couple
of
screenshots
from
the
previous
run,
and
so
we
can
compare
the
output
side
by
side
with
the
actual
pipeline
file
definition.
A
While
one
is
a
variable
and
we
define
the
values
of
r1
as
pulling
in
the
protected
var
variable,
which
we
defined
in
ci
cd
settings,
as
well
as
the
standard
ci
pipeline
id
variable,
and
so
in
the
first
job
output,
where
the
feature
flag
was
not
enabled,
you
can
see
what
the
values
of
results
are.
So
var
one
expansion
works,
okay,
but
then,
when
we
got
to
von
2,
it
did
not
expand
you're,
getting
a
result
here,
where
it's
giving
you
the
string
of
test
for
r2.
A
But
then
it's
just
giving
you
very
odd,
protected,
var
and
then
pipeline
id
var
3
is
doing
the
mass
variable,
okay
and
then
in
terms
of
protected
fog,
equals
protective
file.
That's
working
because
that's
a
very
straightforward
expansion.
Now
with
a
feature
flag,
enabled
right
away.
You
can
see
that
the
variable
2
expansion,
which
is
again
var1
value
appended
to
the
string
test,
is
working
correctly.