vars in a profile not overriding the default vars

[tobalsgithub]

What happened?

If I try to override a var in a profile using the merge option, it does not work.

What did you expect to happen instead? I would expect any var defined in a profile to override the default var section.

How can we reproduce the bug? (as minimally and precisely as possible)

My devspace.yaml:

version: v2beta1
name: bug
vars:
  VAR_1: 'value 1'

pipelines:
  build:
    run: |-
      echo $VAR_1

profiles:
- name: asdf
  merge:
    vars:
      VAR_1: 'value 2'

Then run devspace print -p asdf. You will see that VAR_1 is set to value 1, whereas I would expect it to be set to value 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:

• DevSpace Version: devspace version 6.0.1
• Operating System: linux | mac (seeing on both linux and mac)
• ARCH of the OS: AMD64 | ARM64 Kubernetes Cluster: N/A
• Cloud Provider: N/A
• Kubernetes Version: N/A

Anything else we need to know?

/kind bug

[tobalsgithub]

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'

[tobalsgithub]

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

[tobalsgithub]

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.

[pablorsk]

Confirmed bug :lady_beetle:

Temporal solution

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.

[FabianKramm]

@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.

[tobalsgithub]

@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?

[shaunc]

[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.

[nethi]

I am facing the same issue, patch, replace or merge donot work with variables. Any chance the PR for this will be merged soon ?

[tobalsgithub]

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.