►
Description
Walk-through of how to update your project settings (via API) to only allow users with Maintainer role to change variables when manually running a pipeline.
Documentation referenced in this video:
https://docs.gitlab.com/ee/ci/variables/#restrict-who-can-override-variables
https://docs.gitlab.com/ee/api/projects.html#edit-project
A
First,
let's
take
a
step
back
and
talk
about
what
it
means
to
override
a
variable
documented
here
are
the
six
ways
that
you
can
override.
A
variable
variables
are
usually
defined
in
the
ci,
the
get
lab,
dash,
ci
dot,
yaml
file,
and
there
will
be
times
when
you
may
want
to
run
variables
that
are
slightly
different
than
what's
defined
in
the
ci
yaml
file
for
a
particular
branch.
A
So
let's
say
you
want
to
input
variables
that
are
specific
to
the
test
environment
now,
given
that
is
the
default
behavior,
where
you
can
pass
through
different
variables
than
what
is
the
standard
defined
in
the
ci
configuration.
There
are
times
where
you
want
to
only
allow
users
with
maintainer
role
to
set
those
variables.
A
It's
particularly
relevant.
If
you
choose
to
store
your
c,
I
can
face
in
a
different
repository
a
lot
of
times.
The
reason
you
do,
that
is,
to
prevent
changes
to
the
variables
that
are
run
on
your
more
protected
environments,
let's
say
master
and
the
way
you
would
do
that
is
setting
this
new
attribute
on
the
project
which
the
default
is
that
it's
disabled
by
default.
But
you
can
change
that
false
to
true
and
in
doing
that,
restrict
only
to
the
maintainer
or
or
owner
role,
maintainer
or
above
roles
to
be
able
to
set
these
variables.
A
So
what
I'm
going
to
do
is
I
have
a
test
project
here
that
we're
going
to
play
with
and
first
thing
using
postman,
I'm
going
to
go
out
there.
Let
me
copy
the
project,
the
project
id
and
we're
going
to
go
out
and
confirm
that
that
project
does
in
fact
have
the
default
value
of
false.
For
that
attribute,
everything's,
correct
and
by
the
way
I
am
currently
using
the
token
that
is
relevant
for
the
owner.
A
So
I
do
know
that
that
attribute
is
in
row
line
90,
and
here
we
see
it
here,
okay,
so
it
is
defaulted
to
false.
So
for
this
project
there's
a
few
test
members
I
have
a
test
member
here
which
is
tau
tester
one.
A
I'm
gonna
give
that
tester
the
developer
role,
so
that
we
can
demonstrate
that
as
a
developer,
they
are
able
to
change
the
variables
when
the
current
value
is
false
and
then
we're
going
to
change
it
to
true
and
this
same
user
with
the
developer
role
should
not
be
able
to
to
inject
different
variables,
so
I'm
logged
in
as
tau
tester.
A
Let
me
go
back
so
this
is
me
confirm
this
is
tau
tester
one
running.
Let
me
just
run
it
on
the
test
environment
and
I'm
going
to
put
in
some
variable
happy
trails
I'll
just
put
in
one,
and
it
should
allow
me
to
trigger
the
pipeline
there.
It
is.
The
pipeline
is
running
with
these
two
tests
in
progress
and
we'll
just
ignore
that
the
system
test
job
failed.
Okay.
A
Now,
if
I
go
back
I'll
just
cancel
this,
I
don't
need
that
to
run
we'll
just
conserve
resources
there.
If
I
go
back
before
I
try
to
trigger
on
the
same
environment,
to
make
it
the
same
test
before
I
try
to
trigger
that,
I
am
going
to
change
the
in
postman
change
this
to
true,
so
I'll
just
copy.
This
I'll
add
in
a
parameter
that
one
I'm
going
to
make
the
value
true,
and
I'm
going
to
do
a
put
call
again.
A
So
I
have
here
in
the
request
the
project
id
and
then
this
attribute,
which
is
the
query,
parameter
to
set
to
true
I'm
going
to
send
it.
Okay
status
code,
200,
okay,
we'll
scroll
to
line
90,
and
now
we
see
that
restrict
user
is
set
to
true.
So
going
back
to
our
user,
confirming
this
is
tau
tester,
one
user,
who
now
still
still
has
me
confirmed,
still
has
just
the
developer
role.
A
A
So
we
know
that
now,
with
this
project
attribute
being
true
to
restrict
user
defined
variables,
developer
roles
cannot
change
the
variables
on
when
they
manually
run
a
pipeline,
but
I
should
be
able
to
run
the
pipeline
with
different
variables
and
the
maintainer.
So
I
will
give
tau
tester
the
maintainer
role
now
I'll
go
back
here.
A
Let
me
just
refresh
and
come
back
in
in
case.
I
need
to
do
that.
Let
me
do
it
on
test
again
to
do
the
same
test.
Let's
see
same
variable,
and
this
should
go
through
awesome,
no
error
and
it
started
the
pipeline
to
run
it'll.
It's
a
quick
pause
and
within
30
seconds
those
tests
should
start
running.
So
I
did
confirm
that,
as
this
logged
in
user
tile
tester1,
who
has
the
maintainer
role,
I'm
able
to
trigger
the
pipeline,
even
when
the
restrict
user
defined
variable
is
set
to
true.
A
So
now
you
know
that
if
you
want
to
really
lock
down
strict
controls
to
not
only
where
your
ci
configs
are
stored,
but
also
who
can
change
the
variables
when
running
pipelines
through
any
of
these
six
methods,
you
can
use
this
setting
in
order
to
this
setting
here
on
the
project.
This
attribute,
to
make
it
even
more
secure
hope
that
helps.