►
From YouTube: GitLab CI variables discussion
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone-
this
is
the
mostly
the
beckon
team,
myself
and
marcel
discussing
the
proposal
about
the
valuable
structure
which
originally
was
formed
by
fukan,
but
additional
members
had
expressed
interest
on
adding
their
thoughts
and
comments.
So
the
purpose
of
the
meeting
is
to
go
over
there,
the
problem
and
the
proposed
solution
and
maybe
come
to
some
sort
of
an
agreement
of
what
is
their
going
forward
plan
and
for
khan.
Do
you
want
to
kick
us
off.
B
So
I
just
sent
the
link
of
the
document
of
this
meeting
in
the
zoom.
By
the
way
I
mean
we
can't
go
step
by
step
because
there
it
is
a
large
epic,
and
I
cannot
just
summarize
all
of
them
in
one
sentence,
so
I
mean
our
one
of
the
first
problems
is
that
we
I
mean
we
say
we
need
to
introduce
default
variables,
because,
right
now
we
have
a
top-level
variables
and
it
confuses
our
as
users
workflows.
It
confuses
users
also.
B
It
confuses
us
because
the
top-level
workflow
feels
like
it
is
a
pipeline
variable,
but
it
is
actually
default
variables
for
each
up,
because
that's
why
we
need
to.
B
We
are
trying
to
introduce
the
default
variables
and
in
this
epic,
we
are
discussing
our
options
and
just
introducing
default
variables
does
not
solve
our
problem,
because,
right
now
we
have
rules
to
change
workflow
variables
right
now
and
we
don't
know
how
to
apply
this
default
behavior
for
rules.
B
So
I
think
I
think
one
of
the
discussions
is
about
it,
so
we
can
start
with
it.
B
I
mean,
I
think
we
can
introduce
default
variables
just
now,
but
you
know
we
have.
I
mean
the
I
think,
and
it
is
a
new
feature
that
we
have
workflow
of
rules
variables.
Workplace
variables
is
useful
for
users
because
they
use
it
to
change
their
default
variables
for
each
app.
So
if
we
just
introduce
default
variables
and
if
we
don't
provide
them
rules,
I
think
there
I
mean
there
is
a.
I
mean.
I
think
we
cannot
convince
people
to
move
from
top
level
variables
to
default
variables.
So
it
is
our
goal
here.
B
So
that's
why
I
think
we
need
to
solve
this
problem.
I
don't.
A
Know
like,
like
my
question,
is
more
toward,
like
users
would
ask
for
those
okay,
we
can
say,
let's
introduce
different
variables
without
rules,
but
I'm
pretty
sure
that
one
of
the
first
requirements
we
have
like
add
rules,
and
you
know
it
will
bubble
up
bubble
up
and
get
like
a
lot
of,
and
eventually
we
need
to
add
words
and
generally.
The
question
is
like
I
understand
that
the
answer
is
yes.
Yes,
we
can
introduce
the
default
var
now
and
think
about
rules
later
and
as
as
a
good
first
step.
B
Yeah,
but
one
of
one
of
the
things
that
we
need
to
decide
is
that
we
need
to
block
people
to
use
top-level
variable
with
the
new
default
variable.
So
if
we
introduce
default
variable
we
should
I
mean
we
need
to
block
people
to
use
top-level
variables.
So
that's
why
I
mean
we
cannot
convert
all
people,
but
we
can
convert
most
of
the
people
that
use
tuple
variables.
A
Yeah,
I
mean,
I
think
the
way
to
do
it,
and
I
think
like
blocking
is
like-
maybe
you
know
persuading
them
to
to
replace
the
top
level
variables
with
with
different
variables
is,
is
with
all
the
challenges
that
they
have
today,
like
with
all
the
challenges,
and
there
are
like
many
many
problems
with
you
know
a
child
and
multi-project
pipeline
and
the
way
they
inherit
those
and
with
the
ui
so
they're
like
and
you
you
describe
all
of
it
really
well.
A
I
think
that
one
way
like
we
can
do
several
several
actions
like
first
of
all,
obviously
documentation
and
we
need
to
deprecate
the
top
level
variable
and
deprecate
not
remove,
but
just
deprecate
and
just
make
it
disappear
from
from
our
documentation.
This
is
number
one
number
two
tell
all
the
users
hey.
If
you
want
to
override
your
problem,
here's
the
solution
like
use
the
default
variable.
A
It
will
take
time
and
it
will
take
time,
but
every
time
a
user
will
hit
this
problem,
we'll
tell
we
need
to
tell
them
I
mean,
maybe
we
can
even
blog
about
it.
We
can
post
it
there,
so
so
users
will
be
aware-
and
hopefully
this
way
gradually
we'll
see
users
moving
from
the
top
level
variables
to
the
different
variables.
C
C
In
my
opinion,
we
can't
raise
an
error
say
you
can't
use
both
of
them
at
the
same
time
like
like
a
static
error,
because
that
might
not
be
in
control
of
the
user
running
the
pipeline
or
the
author
of
that
pipeline.
So
they
might
need
to
contact
the
owner
of
the
template.
They're,
including
and
say:
can
you
please
change
upgrade
your
configuration?
Otherwise
I
can't
use
mine
or
whatever.
C
Maybe
what
thing
we
could
do
is
that
default
variable
will
have
a
higher
precedence
than
top
level
variables
so
because
the
newer
syntax
we
document
these
and
we
will
different.
We
need
to
deprecate
that
there's
two
options.
It
is
the
hard
option
of
raising
an
error,
but
that
could
be
disruptive
for
people.
A
Yeah,
I
think,
includes
the
include
yeah.
The
include
example
is
a
good
one.
The
question
is
like:
if,
if
we
will
make
like
default
variables
like
higher
precedence,
does
it
solve
the
problems
that
we
see
users,
you
know
with
with
ui
variables,
with
the
preferred
variables
we
because,
like
this
is
the
I
mean
the
the
main
problem
that
we
see
is
about
that.
A
It's
about
all
those
problems
that
are
appearing
to
users
in
different
scenarios
and-
and
I
think,
like
fukan's
suggestion
is
hey
like
use
this
this
this.
This
will
be
like
the
way
you'll
be
able
to
walk
around
some
of
those
problems
by
simply
moving
it
to
be
like
a
default
variable.
So
the
question
is:
will
it
solve
the
other
problem
that
we
see
in
this
issue
or
in
this
epic.
D
Yeah,
perhaps
we'd
ask
what's
the
key
problem
like
like
what
what's
what
are
we
trying
to
get
to
in
the
end,
because
it's
not
clear
to
me
how
like
this,
I
like
this
idea
just
from
a
pure
like
understanding
point,
but
it
had
it's
still
not
clear
to
me
like.
What's
the
end
goal,
and
I
think
it
was
more
towards
inheritance
with
child
pipelines,
and
things
was
what
kind
of
really
got
us
thinking
a
lot
about
that.
So
I'd
just
like
to
hear
how
how
it
all
connects.
B
According
to
me,
the
problem
we
need
we
are
trying
to
solve
is
to
get
rid
of
the
top-level
variables
because
it
is
just.
It
is
just
my
opinion,
because
top-level
variables
is
confusing.
It
is
like
pipeline
variables,
but
it
is
actually
not
a
pipeline
variable.
It
is
actually
job
variables,
but
sometimes
we
use
it
as
a
pipeline
variables.
For
example,
the
prefil
variables
feature.
C
Is
that
like
what
the
way
I'm
seeing
is
that
using
default
variables
is
a
syntax?
It
solves
like
a
syntax
confusion,
but
the
behavior
will
remain
the
same.
We
are
not
adding
a
feature.
We
are
making
clear
the
the
syntax
clear,
cleaner
right.
B
E
C
C
B
So
we
have
another
problem
with
the
top
level
variables
right
now
we
have
a
feature
workflow
of
rules
variables
and
in
that
feature
we
are
trying
to
override
top-level
variables
in
workflow
of
rules
variables.
So
that's
another
conversion,
so
I
mean
yeah.
There
are
three
problems
we
can
say.
D
B
D
B
D
D
B
Yeah,
but
we
are
also,
I
mean,
I
think
we
are
also
not
sure
about
introducing
pipeline
level
variables
in
ci,
because
I
don't
know
if
we
need
it
or
not.
We
don't
know
that
because
when
you
def,
I
mean
when
you
want
to
introduce
a
pipeline
level
variable,
you
can
just
use
job
level
variables.
Why
do
you
use
pipelineable
variables,
for
example,
but
it.
D
Maybe
we
can
do
it
for
pipeline
variables
because
that
would
be
considered
part
of
that
pipeline
and
it
should
be
passed
on
to
the
child
while
job,
it's
really
easy
to
see.
Well,
if
it's
in
a
job
it
should
stay
within
the
job
and
so
default
variables
would
again
stay
within
the
job
and
that's
the
confusion,
because
you
put
default
variables
at
the
top
level
of
the
pipeline.
B
Actually,
we
are
passing
default
variables
to
the
downstream
pipelines
yeah,
because
I
mean,
let's
think
about
like
that.
So
our
I
mean
how
we
pass
variables
to
downstream
pipelines
works
in
I
mean
when
you
have
a
yaml
defined
variable
in
the
breed
job.
B
Right
now
we
are,
we
are
doing
it
already.
By
the
way
I
mean
the
top
level.
Variables
is
the
default
variables,
so
we
are
passing
to
downstream
pipelines,
and
this
is
also
another
confusion
in
an
issue
that
I
mean
they
say
I
am
defining
a
pipeline
level
variable
here,
but
they
are
pressed
to
downstream
pipelines,
but
they
don't
know
it
is
actually
job
variable.
A
A
For
the
downstream
pipeline
we
introduce
the
pipeline
variable
and
say:
okay,
this
is
the
variable
for
this
downstream
pipeline.
No
one
can
override
it
yeah,
but
I
think
it's,
I
think
it's
it's
probably
a
separate
problem.
I
mean
it
is
confusing,
but
I
think
that
if
we
will
explain
to
them,
why
are
we
doing
that?
A
And
what's
the
logic
behind
that,
then
they
will
understand
so.
Okay
next
thing,
please,
let's
add
like
a
pipeline
that
this
way
we
can,
we
can
gradually
like
add
additional
features,
and
I
think
one
of
the
problems
that
we
have
also
like
another
problem
is,
but
we
talk
about
it.
It
is
the
prefer
the
pre-filled
variable
it
becomes
like
like
you,
you
define
it
as
a
yaml
variable,
but
when
you
pre-fill
it
in
the
ui,
it
becomes
variables
pop
a
pipeline
variables
and-
and
I
think
this
is
the
this
is
one
of
the
problem.
A
Like
the
user
say:
hey
like
this
is
just
the
pipe.
This
is
just
a
variable
that
I'm
defining,
but
the
minute
I
will
use
the
ui
to
define
it.
You
automatically
like
change
everything
like
change
the
the
president,
so
my
pipeline
now
works
differently,
just
because
I
have
a
nicer
way
to
add
this
pipeline
through
the
ui.
So
why
are
we
doing
that?
B
Yeah,
I
remember
fabio
has
a
suggestion
in
the
epic
that
let's
not
define
a
value
for
preferable
variables.
B
Let's
just
define
the
description
for
the
variables
and
we
can
just
populate
them
in
the
pipeline
new
page
and
they
will
know
that
it
will
overwrite
everything.
But
yeah
I
mean
if
we
do.
If
we
allow
people
to
write
pipeline
variables
in
ci
yml,
it
may
feel
like
that
you
can
overwrite
them
in
the
job
level.
B
C
C
It's
more
like
we
could
use
reuse
whatever
we
currently
have.
We
have
a
workflow
top
level
keyword
and
we
could
reuse
that
maybe
well.
C
The
idea
is
like
to
use
something
like
prompts
and
and
then
a
var
one
by
two,
so
where
those
will
be
only
description
that
are
available,
but
they
are
not
actually
used
as
to
collect
values,
because
that
will
be
the
equivalent
of
defining
pipeline
level
variables
which,
as
I
said
there
in
the
in
a
meeting
agenda,
there
is
there's
a
concern
with
pipeline
level
variables
to
be
in
a
yaml,
because
they're,
the
precedence
is
too
high.
C
C
And
we,
where
we
don't
want
to
have
a
configuration
to
override
those,
but
we'll
still
can
override
them
like
a
pipeline
level
and
but
having
those
in
the
configuration
could
also
be
like
a
problem
because,
basically
you're
defining
a
pipeline
of
a
variable
that
can
be
can't
be
overridden
right.
If
that's
my
concern,
we're
using
the
pipeline
variables
like
in
the
conflict.
C
C
D
I
just
want
to
understand
it
if
they
don't
add
the
value
in
the
ui
and
just
because
right
now
you
in
the
configuration
file,
you
can
put
a
value
and
a
description.
So
if
they
don't
put
it
in
the
ui,
is
it
a
pipeline
variable
or
a
job
variable.
C
D
A
D
A
A
It
feels
like
it
feels
like
it
feels
like
a
bug,
but
I'm
not
sure
if
this
is
something
we
can
change
today,
because
this
became
like
an
established
behavior
so
like,
and
I
think
this
is
one
of
the
problem
that
we
need
to
try
to
solve.
Can
we
somehow
define
a
variable
in
a
different
way
that
if
we
will
populate
it
through
the
ui,
it
will
still
remain
the
way
it
was
defined
in
in
the
yaml,
because
we
are
just
like
updating
the
value
like
for
the
user,
they
think
hey.
A
A
Should
there
be
a
difference
and
like
in
terms
of
like,
if
we
look
at
like
what
users,
how
users
will
use
it
so
think
about,
there
is
like
a
team
that
is,
that
is
creating
those
templates,
those
creating
those
it's
actually
it's
templates.
So
this
is
why
your
your
example
fabio
makes
sense
about
the
include,
but
it's
a
separate
topic,
so
they
create
like
this
template,
for
instance,
that
is
doing
some
sort
of
a
deployment
for
aws
and
and
then
they
test
it.
They
they
use
it
to
say
it's
great
now.
A
Let's
make
sure
that
the
users
of
those
templates,
like
all
the
engineers
that
now
need
to
need
to
deploy,
for
instance,
this
application
will
have
a
slick
way
to
do
it
with
the
ui
and
we'll
tell
them
hey
like
if
you
want
to
define
it
to.
I
know
in
this
way
just
add
those
parameters
in
the
ui.
If
you
want
like
another
way,
add
those
variables
the
value
of
the
variables
to
the
ui,
but
the
minute
they
do
that
the
entire
behavior
of
the
pipeline
is
changing
and
they're.
Saying
hey
it's
a
bug.
A
A
A
C
But
I
think
there
it's
also
probably
we
used
the
existing
pipeline
variable
form
in
the
create
pipeline
variable
form
to
to
inject
this
new
pipeline
use
the
defined
pipeline.
So
if
when
we
were
when,
when
you
click
on
run
pipeline-
and
you
are
redirected
to
this
new
form,
you
we
had
even
before
the
ability
to
say
I
want
to
insert
manually
this
variable
now,
what
do
we
do
and
those
were
pipeline
variables
they
were
being
applied
to
into
the
entire
pipeline,
and
but
we
reuse
the
same
form
to
say.
C
Okay,
now
we
can
display
more
inputs
based
on
the
configuration.
So
if
we
use
the
same
input,
then
those
will
become
pipeline
variables,
it's
a
kind
of
a
consequence
of
the
tool
that
we
used
as
well.
So
if
you
want
to
say
that
okay,
this
job
uses
this
variable,
but
I
want
to
expose
to
the
ui,
so
somebody
can
specify
more
like
a
variable,
as
this
job
runs.
C
So
it's
more
like
a
variable
that
is
inputted
by
the
user
by
the
ui,
but
should
be
applied
only
at
job
level.
It
sounds
like
it's
more
like
this
right
to
say
so.
Maybe
we'll
have
like
a
list
of
jobs
with
some
of
these
jobs,
we
can
have
some
variables
and
you
can
specify
the
variable
for
these
jobs
and
say
yeah,
dr
aws
token,
only
for
the
deploy
job
and
it
will
not
be
an
aws
token
that
is
actually
applied
to
the
entire
pipeline.
C
A
A
I
wonder
if,
like
like
one
way
of
solving,
it
is
actually,
if
you,
if
you
do
it
with
the
ui,
is
actually
go
to
the
ui,
and
when
you
mention
a
variable,
you
can
define
if
it's
like
a
pipeline,
variable
or
or
a
job
level
variable
pipeline
malibu
is
the
default.
So
this
is
how
it
works
today,
but
at
least
in
order
not
to
introduce
breaking
changes,
you
can
say
hi
like
I
want
to
change
the
type
of
this
variable
to
be
like
a
no
to
not
be
like
a
pipeline
variable.
C
C
C
Was
that
considered
too
powerful
of
a
part
of
a
variable,
because
then
it
was
was
being
exposed
to
all
the
jobs,
not
just
the
specific
job
where
that
input
was
required.
Was
this
like
a
problem
that
we
had
seen?
Because
I'm
not
sure
whether
now
is
the
pre-failed
variables
is
too
powerful
because
it
makes
them
as
a
pipeline
variable
as
well
should
probably
be
like
a
job
variables.
A
A
So,
like
user
didn't
didn't
understood
that
when
you
define
a
variable,
the
top
level
keyword,
it
copied,
basically
all
the
variable
to
a
job,
and
if
you
it
is
copied
to
a
trigger
job-
and
it
is
passing
through
to
a
child
pipeline,
but
that's
an
ex
an
expected
behavior,
although
also
when
we
move
it
to
a
downstream
pipeline,
becomes
like
a
pipeline
viable,
which
is
which
is
a
problem
by
itself.
But
I
think
that
we
can
like.
A
We
can
explain
why
we
are
doing
it
and
maybe
we
can
differentiate
between
pair
and
child
like
we
have
some
wiggle
room
here
and
say:
okay
for
like
multi-project
pipeline,
we
don't
do
that
for
parent
pie
charts
when
we
do
that,
because
this
is
the
parent.
This
is
john.
This
is
inheriting
everything
so,
and
I
think
we
have
also
the
inherent
keyword
where
we
can
define
what
not
to
pass
so
like.
There
is
a
way
for
users
to
like
to
somehow
override
that.
A
So
so
I
think
it
could
be
easily
not
easily
but
like
some
way
alleviate
this
problem
by
using
the
different
variables,
maybe
also
add
some
some
examples
in
the
documentation.
This
is
number
one.
Okay,
we
can
do
that,
I
think
even
today,
and
then
we
can
talk
about
what
we
do
with
rules
and
everything
we
can
discuss
about
it
later.
A
The
the
biggest
problem
that
I'm
seeing
is
is
that
the
fact
that
we
took
like
the
pipeline
variable
for
the
run
pipeline
feature
and
we
reuse
it
for
for
running
a
manual
job,
for
instance,
just
like
running
running
a
job
and
adding
the
pipeline
to
that,
and
we
are
going
to.
A
We
are
going
to
enhance
this
feature.
Actually
we
are
going
to.
We
want
to
allow
users
to
we
run
like
a
manual
and
and
not
manual
job
by
adding
more
variables.
So
we
have
like
an
epic
for
that.
So
it
means
that
we
need.
We
need
to
get
it
right,
because
if
not,
we
will
basically
like
screw
up
the
entire
pipelines.
When
we
do
that-
and
I
think
this
was
not
an
expected
behavior.
A
If
I'm,
if
I
define
a
variable
in
a
job-
and
it's
like-
and
this
is
the
type
of
the
variable,
we
should
not
change
the
presence
simply
because
the
way
we
input
it
because
now
we
have
like
another
way
to
input
this
variable.
So
I
I
would
say
I
think
this
is
like
I've
seen
we've
seen
users.
I
can
dig
too,
and
I've
seen
this
confusion
emerging
from
the
problem
like
why.
Why
is
it
overriding
everything
why
this
valuable
now
behave
differently?
Just
because
I
added
to
the
ui.
C
It
could
be
that
so
it
could
be
that
anything
that
is
fulfilled
variables
can
have
a
precedent
that
is
higher
than
yaml
variables,
but
lower
than
any.
You
just
write
like
just
after
vmware
variables
like
below
pipeline
variables
or
or
group
variables,
or
anything
else,
so
it's
not
as
powerful,
so
it
will
be
equivalent
to
say
grab
all
the
variables
from
whatever
top
level
variables
or
default
variables
apply
those
to
the
jobs.
But
then,
if
I
input
the
same
variable
by
the
pipeline
form
replace
that
job
level
variable
with
this
value.
C
So
if
the
same
variable
is
used
in
multiple
jobs
that
will
be
replaced,
but
would
not
be
as
pipeline
variable
like
as
high
as
a
pipeline
variable,
because
that
would
allow,
if
you
want
to
run
a
specific
job
manual,
job
with
a
specific
variable
that
want
that
to
have
a
higher
precedence.
It
will
not
be
overrated
by
the
pipeline
variable
that
was
inputted
in
the
form
when
the
pipeline
was
originally
executed.
E
Yeah,
I
think
we
could
do
that
because
we
have
a
database
table
called
ci
job
variables
in
which
we
store
job
variables.
The
dot
m
source
and
this
table
has
a
type
column.
So
we
could
store
in
there
a
new
type
of
variable
and
we
could
add
it
in
the
contextable
module
with
a
set
precedence
higher
than
the
default
ml
variables.
E
D
Perspective,
what
what's
the
benefit
of
the
pipeline
variables,
because
we
we
don't
even
really
document
the
concept
of
pipeline
variables.
Just
we,
we
document
precedence
in
a
sense
and
I'm
just
we.
We
just
say
that
jobs
added
at
the
in
the
ui
have
more
precedence
than
jobs
added
in
the
in
the
config
file.
So
like
what?
Why
do
we?
This
is
more
a
back
end
that
I'm
not
really
going
to
understand.
D
But
why
do
we
even
really
have
pipeline
variables
like
what,
because
fabio
said
it's
it's
more
powerful
and
then
it's
almost
too
powerful
and
then,
when
we
pass
a
job
variable
to
a
child
pipeline,
it
becomes
a
pipeline
variable.
Has
that
become
too
powerful
in
the
context
of
the
child
pipeline
now,
so
I'm
a
bit
confused
as
as
to
the
benefit
of
the
whole
pipeline.
Variable
concept
itself.
B
No,
I
mean
my
understanding
from
the
pipeline
variables
is
that
it
is
a
flexible,
so
you
can
run
a
pipeline
with
that
way
and
you
can
run
the
same
pipeline
with
that
way.
Also,
you
can
trigger
at
same
pipe
a
child
pipeline
with
x-ray
and
you
can
trigger
the
same
child
pipeline
with.
Why
way.
So
that's
why
the
pipeline
variable
is
actually
useful
for
some
cases
we
don't
know,
maybe
we
maybe
we
don't
use
it
at
all,
but
I'm
sure
some
people
use
it
in
a
very
different
way
and
useful
for
them.
B
So
I
also
want
to
say
about
the
fabulous
idea
and
mario's
idea,
so
I
mean
if
we
change
the
permission
levels
of
pipeline,
I
mean
I
I
mean
I
don't
think
we
should
change
the
permission
levels
of
variables.
I
mean
if
we
have
some
set
of
rules,
so
one
rule
is
that
when
you
enter
a
pipeline
enter
a
variable
in
the
pipeline
form,
it
will
write
everything.
So
it
is
our
setup
rule.
When
you
run
a
manual
pipeline,
it
will
become
a
job
variable
and
it
will
overwrite
every
variable
for
this
job.
B
So
this
is
our
set
of
rules,
and
I
think
it
I
think
they
work
perfectly
in
itself,
so
I
mean
because
they
have
some
set
of
rules
and
they
do
their
job.
I
don't
think
we
should
change
that,
but
I
I
mean
I
know
our
confusion
is
that
we
write
something
on
the
yaml.
We
overwrite
this
into
ui
and
it
will
overwrite
everything.
B
So
I
write
something
here
that
I
mean
how
about
having
project
level
triple
variables
instead
of
defining
them
in
dml,
so
let's
not
define
them
in
the
ml,
but
let's
define
them.
Okay,
we
have
cicd
settings
in
the
project
and
we
have
variables
in
there.
Maybe
we
have
a
checkbox
in
some
variables
that
okay,
I
want
to
prompt
that
in
the
pipeline
run.
So
we
are
right
now
migrating
our
peripheral
variables
feature
from
yaml
to
project
ci
cd
settings.
So
maybe
we
can
do
that.
E
I
think
that
one
might
be
a
problem
if
users
are
using
different
branches
to
have
different
prompts
for
each
branch.
B
Yeah
correct,
I
mean,
I
don't
know
if
people
really
use
the
preferable
variables
that
flexible,
I'm
not
sure
about
that,
I
I
don't
think
they
will
you,
but
if
they
need
that
okay,
but
you
know
we
also
have.
I
think
we
also
have
branch
feature
in
our
ci
cd
settings
variables
right.
Do
we
have
that
I
mean
we
are.
We
are
setting
some
variables
to
be
available
in
some
branches
or
not.
Maybe
it
is
just
about
protected
branches.
Maybe
I
don't
remember
very
well.
I
think.
B
Okay,
so
so
so
I
don't
remember
it
very
well,
but
I
don't
think
users
use
that
peripheral
variables
that
flexible
or
they
they
can
just
ignore
them.
For
example,
I
mean
they
can
they
can
just
ignore
them.
I
mean
because
users
have
a
ci
cd
settings
and
they
define
some
peripheral
variables
and
when
someone
opens
the
pipeline
rampage,
they
see
the
peripheral
variables
in
them
and
they
can
just
ignore
them.
D
D
B
D
Well,
I
I
just
kind
of
was
wondering
if
there,
if
people
would
see
some
benefit
to
to
having
kind
of,
if
then
in
a
sense
with
with
variables
such
that,
if
there's
to
to
be
able
to
I'm-
probably
just
misunderstanding
it
to
me
in
my
head,
though,
it
seems
like
if
you're
defining,
pre-filled
variables
like
without
a
value
for,
for
example,
like
one
of
fabio's
ideas.
It's
not
immediately
clear
to
me
how
you
would
make
use
of
that
such
that.
D
If
it's
not
filled,
then
I
want
to
use
my
default
one,
and
then
then
I
I'm
just
kind
of
imagining
how
I
would
explain
to
people
how
how
they,
how
they
would
use
this
and,
like
the
the
pre-filled
variables,
didn't,
seem
to
have
any
value
to
me
at
the
beginning
of
this
conversation,
but
slowly
I'm
I'm
starting
to
see
kind
of
what
everyone
was
saying
and
I'm
like
okay.
This
is
starting
to
make
a
lot
more
sense,
but
how
would
I
use
this
in
my
config
is?
Is
the
challenge
that
I'm
getting
at
now?
B
Aft
I
mean
after
seeing
them
in
the
pipeline
rampage
after
seeing
them
in
that
form
and
writing
a
value
or
not
they
will
I
mean
they
will
be
pipeline
variables.
I
mean
regular
pipeline
variables,
that's
all
I
mean
if
right
now,
if
you
can
use
a
pipeline
variables
in
rules,
you
can
use
them,
so
it
is
not
different.
D
D
C
We
are
adding
the
description.
Basically,
we
are
using
to
display
the
the
the
fields
for
the
variable.
It's
purely
metadata,
it
doesn't
add
any
behavior,
it
doesn't
add
anything
anything
I
mean
if
I
run
the
same
pipeline
by
api
or
it
will
completely
ignore
whatever
is
in
the
description
or
in
workflow,
prompts
or
securely
metadata
for
configuration
that
is
used
to
render
something
like
an
html
form,
and
so
because
this
is
not
a
pipeline
configuration
because
it's
you
know
it.
E
C
Add
any
configuration
to
to
the
pipeline
and
I'm
wondering
whether
these
should
actually
be
something
that
is
in
the
configuration
in
the
project
configuration
to
say.
I
want
to
configure
my
pipeline
ui
and
with
this
information,
and
you
add
it
there
and
still
well,
there
will
still
be
calm
like
pipeline
variables
or
we
can
say,
set
these
as
a
job
level
variables
whatever
we
want.
We
want
to
do
it,
but
basically
it
will
not
add
anything
to
the
to
the
pipeline
configuration.
Well,
it's
more
like
a
ui
setup.
C
In
that
case,
we
don't
need
to
rely
on
the
description
or
workflow
prompts
or
anything
the
backlines
just
simply
behave,
because
I
think
one
interesting
aspect
we
need
to
maintain
standard
is
that
the
same
configuration
should
work
the
same
way
like,
even
if
it's
like
a
by
api
or
a
scheduled
pipeline.
Of
course,
there's
those
like
source
also
changed
the
structure
of
the
pipeline,
but
the
this
specific
configuration
keywords
that
we
are
adding
doesn't
add
any
configuration
changes
to
the
pipeline.
So
that's
my
main
concern.
E
C
A
pipeline
ui
configuration
where
you
decide.
Okay,
I
want
to
add
a
field
for
for
this,
and
that
will
would
would
that
be
still
a
pipeline
variables.
Maybe
it's
expected
behavior.
You
know,
because
eventually
you
still
can
provide
the
pipeline
variables
in
the
form,
as
is
today
even
without
having
any
pre-filled
variables.
You
can
still
do
it
manually.
C
That
is
more
kind
of
a
handy
feature
to
to
provide
like
a
little
more
like
a
better
ux
on
that,
and
that's
why
I'm
saying
like.
Maybe
this
could
be
something
we
can
provide
to
customize
your
ui,
your
pipeline,
ui
and
but
having
that
as
a
project
level
variables.
C
I'm
not
sure
that
is
a
good
idea,
because
sometimes
I'm
not
I'm
not
sure,
but
like
sometimes
there
could
be
even
some
pipeline.
There's
some
some
variables
keys
that
we
don't
want
to
expose.
So,
like
only
maintainers
know
what
kind
of
keys
are
there?
It's
still
fine
to
you
know
to
it.
It
might
still
be
possible
to
display
what
what
variables
are
in
a
job,
but
but
we
might
not
want
to
expose
like
what
keys
are
available,
because
I'm
still
not
sure,
like.
C
Expose
the
existence
of
the
name:
okay,
what?
If
that
is
like
a
default
token,
that
should
be
secure,
but
then
you
want.
You
want
to
override
that,
like
a
is
a
user
able
to
inspect
what
kind
of
value
was
there
originally,
I'm
not
sure,
like
both
the
keys
involved,
but
also
the
keys
that
might
be
a
problem
or
is?
Is
the
president
correct
and.
A
Put
away
the
just
the
the
key
is,
what
you
just
described
is
one
of
one
of
the
top
requests
that
we
have
form
a
pre-filled
variables
users
would
like-
and
this
is
something
that
we
may
end
up.
Adding
users
would
like
to
add
like
what
are
the
options?
Even
what
are
the
options
that
users
can
add
to
a
variable,
because,
as
I
mentioned
in
a
lot
of
cases,
there
are
two
teams,
one
team
that
is
creating
the
template
or
the
pipeline.
A
A
C
About
keys,
but
there
is
some
permissions
problems
where
today
only
maintainers
are
allowed
to
see
project
level
variables,
for
example,
and
if
we
want
to
use
that
feature
to
say
expose
this
to
the
ui
as
a
pre-filled
variables,
then
we
are
actually
allowing
any
other
users
to
see
what
project
level
variables
are
there,
even
though
they
might
be
treated
differently
according
to
the
permission.
But
I'm
wondering
that
is
like
a
are:
we
using
the
right
tool
again
there
or
are
we
yeah?
Is
it
something.
B
I
I
have
two
things
to
say
about
this,
so
one
thing
is
that
you
I
mean
a
maintainer
or
owner
of
the
project
can
choose
what
variables
to
be
shown
in
the
ui.
That's
the
one
thing.
The
other
thing
is
that
I
liked
your
idea
that
it
is
actually
a
ui.
I
mean
the
pipeline
ui
problem.
Maybe
so
maybe
it
is
not
about
the
project
crcd
settings.
B
Maybe
it
is
not
about
yaml
settings,
maybe
maybe
we
need
to
have
another
setting
for,
for
example,
pipeline
settings,
or
I
know
I
don't
know
the
name,
but
maybe
we
can
do
that,
but
I
also
changed
my
mind
about
having
them
in
the
project
level,
because
and
with
that,
we
are
also
confusing
people
about
the
permissions,
because
right
now
our
what
is
our
main
problem.
If
we
are
writing
a
top-level
variables,
it
is
actually
default
variables,
but
when
you
pre-populate
them
it
will
become
pipeline
variables
right.
B
But
when
we
convert
a
project
level
variable
into
the
ui
and
when
you
overwrite
them-
and
it
will
all
write
everything,
so
it
will
also
starts
initiate
another
permission,
priority
problem.
So
that's
why
I
mean
I
changed
my
mind
about
project
level.
Maybe
we
can
find
we
should
find
another
solution.
As
five
you
said.
A
Okay,
I
think
I
think
are
we
are
we
are
at
time
now
and
I
want
to
make
sure
to
respect
other
people's
time.
I
want
to
understand
if
we
can
have
some
sort
of
an
action
item
in
the
follow-up
I
mean.
Obviously,
we
won't
agree
everything
and
won't
find
a
solution
for
all
the
problems
that
we
have
today,
but
like
what
should
be
our
next
step?
Is
it
like
introducing
the
default
variables
without
rules?
A
As
you
mentioned,
your
proposal
at
the
beginning
and
adding
more
make
sure
we
make
sure
it's
clear
in
the
documentation
about
you
know
how
you
either
ui
variables
now
become,
even
if
you
define
it
as
like,
like
a
different
variable
become
pipeline
variable
should
those
be
like
the
main
two
things
that
we
need
to
start
doing
and
then
maybe
reconvene
again
and
try
to
solve
other
problems,
because
it
feels
that
there
is
so
much
and
we
need
to
take
it
like
step
by
step.
C
In
my
opinion,
we
could
start
with
tackling
the
probably
the
prevailed
variables
like
outside
the
default
variables,
or
you
know
solving
that
kind
of
ambiguity,
and
but
are
we?
C
What
I'm
learning
was
from
this
meeting
is
that
we
might
have
users
that
consider
surprising
the
behavior
that,
when
they
pre-fill
a
variable
from
the
ui
that
becomes
a
pipeline
variable
and
it's
not
what
they
expected
so
and
once
again
like.
Even
if
we
move
the
pre-filled
feature
like
for
defining
what
the
labels
display
in
the
ui
from
the
ci
configuration
we
put
into
somewhere
in
the
project
settings
that
eventually
becomes
pipeline
variable,
because
that
will
be
prompted
in
the
same
form
and
the
user
fill
in
and
it
becomes
a
type
of
error.
C
C
A
Yeah,
I'm
not
sure,
I'm
not
sure
we
have
an
answer
for
that.
One
of
the
problems
is
again
since
there
are
like
so
many
problems.
Everything
is
bubble
is
bubbling
up
and
you
have
this
problem
and
that
problem
another
one,
it's
very
hard
to
distinguish
between
the
noise
and
the
real
problem.
This
is
why
my
proposed
next
step
is
just
like
make
sure
things
are
clear
because,
as
fulcan
mentioned,
that's
our
this
is
how
they
work
and
they
work
fine.
Is
it
like
the
right
rules
for
our
users?
A
Maybe
yes,
maybe
you
know
the
problem
is
because
those
rules
are
not
like
documented
well
in
terms
of,
like
you
know,
examples
in
the
ui
things
that
we
are
really
missing.
Then
customers
are
getting
surprised-
maybe
maybe
it's
okay,
but
still
it's
surprising
to
them
that
you
know
when
you
you
configure
something
and
then
you
add
the
variable
to
a
different
way,
change
completely
everything.
A
A
C
C
This
actually
would
result
if
we
extract
the
the
pre-filled
variables
from
the
ci
config
would
actually
avoid
use.
I
was
using
the
yaml
processor
to
list
these
variables.
It
could
be
listed
directly
from
some
conflict
records
we
have
yeah.
I
think
it
will
be
also
like
a
nice
kind
of
protected
removal.
D
We
we
also
brought
up
a
lot
of
problems
in
this
call
column.
I
wonder
if
we
could
kind
of
list
what
what
are
the
current
issues
like
with
variables
like
in
in
one
place,
because
we
we
do
have
a
a
bunch
of
different
issues.
We
do
have
the
epic
do.
A
That
we
need
to
solve
each
problem
and
maybe
we
don't
need
to
solve
it.
That's
what
I'm
saying.
Maybe
maybe
this
is
the
way
to
work
but
needs
to
be
very
clear.
So
maybe
I
don't
know
some
inconsistency
or
something,
but
we
need
to
find.
We
need
to
find
some.
But
okay,
let's
list
like
those
bullets
and
that
our
users
are,
you
know,
are
challenged
with
and
and
we
can
you
can.
You
can
add
this
as
an
action
item
I
can.
I
can
try
taking
this
one
and
maybe
if
fukan
fabio
could
help
me.