Open tobalsgithub opened 2 years ago
fwiw, it doesn't look like patch
or replace
work for overriding vars
either.
version: v2beta1
name: bug
vars:
VAR_1: 'value 1'
pipelines:
build:
run: |-
echo $VAR_1
profiles:
- name: asdf
merge:
vars:
VAR_1: 'value 2'
- name: patch
patches:
- op: replace
path: vars.VAR_1
value: 'value 3'
- name: replace
replace:
vars:
VAR_1: 'value 4'
Switching the profile to use alwaysResolve: true
also doesn't seem to help.
profiles:
- name: asdf
merge:
vars:
VAR_1:
value: 'value 2'
alwaysResolve: true
Variables that are ONLY defined in the profile section seem to show up correctly. So to me, this looks like the merge order got reversed from what I would expect, with default vars overriding profile vars, instead of the other way around.
Confirmed bug :lady_beetle:
profiles:
- name: all
activation:
- vars:
DEVSPACE_PROFILE:
patches:
merge:
vars:
APP_ENV: 'local'
- name: production
merge:
vars:
APP_ENV: 'production'
And APP_ENV
was removed from vars
section.
@tobalsgithub thanks for reporting this issue! Mhh, I believe this is caused because DevSpace initially resolves the variables, but then when the profile was applied is not updating those anymore internally.
@pablorsk I gave your workaround a shot, but am not able to get it to do what I want.
In our case, we have a bunch of "default" environment variables that we set at the top level, outside any profile. We then want any profile to be able to override those defaults as they need.
It seems like what's happening here is that the all
profile isn't actually getting activated when I explicitly specify a profile: ie devspace print -p production
.
The documentation on activation isn't totally clear to me in terms of how activation works with explicitly listing out profiles with the cli. Does activation work when a profile is listed explicitly (my experience suggests no)? If so, which profile takes precedence? Can you activate more than one profile at the same time like you can by listing more than one profile from the cli? If so, which one takes precedence?
@FabianKramm any chance this gets fixed in an upcoming release? I'm somewhat surprised more folks aren't running into this, but perhaps our setup isn't common?
[Ugly workaround] FWIW you can make config variables calculate their value based on environment variables.
vars:
STAGE: |-
$( if [ "$DEVSPACE_PROFILE" == "production" ]; then
echo "prod"
else
echo "test"
fi
)
Unfortunately this doesn't work just with --profile=production
, but if you export DEVSPACE_PROFILE=production
it will work.
I am facing the same issue, patch, replace or merge donot work with variables. Any chance the PR for this will be merged soon ?
For anyone following along, it appears that this has been fixed in the most recent version of devspace: 6.2.3. I don't know when specifically it was fixed, but variables from profiles appear to be resolving correctly now.
The example above now shows value 2
when running devspace print -p asdf
.
What happened?
If I try to override a
var
in a profile using themerge
option, it does not work.What did you expect to happen instead? I would expect any
var
defined in a profile to override the defaultvar
section.How can we reproduce the bug? (as minimally and precisely as possible)
My devspace.yaml:
Then run
devspace print -p asdf
. You will see thatVAR_1
is set tovalue 1
, whereas I would expect it to be set tovalue 2
. This worked as expected in the beta version of v6, but stopped working when we upgraded to version 6.0.0 and still does not work on version 6.0.1.Local Environment:
Anything else we need to know?
/kind bug