devspace icon indicating copy to clipboard operation
devspace copied to clipboard

Backwards compatibility issue with cross config variable references

Open connor-philip-ci opened this issue 3 years ago • 3 comments

What happened? I updated devspace from version 5 to 6, using the config version v1beta9 and ran into this error when trying to deploy: create_deployments: error deploying Y: couldn't find runtime variable runtime.dependencies.X.images.x.image, make sure the dependency X was loaded

What did you expect to happen instead? For the file to be backwards compatible.

How can we reproduce the bug? (as minimally and precisely as possible) Try using cross file variable references, using config version v1beta9, with devspace v6.

My devspace.yaml:

version: ...
...

Local Environment:

  • DevSpace Version: 6.1.1
  • Operating System: mac
  • ARCH of the OS: ARM64 Kubernetes Cluster:
  • Cloud Provider: aws
  • Kubernetes Version: 1.21
  • Kubectl 1.22

Anything else we need to know?

/kind bug

connor-philip-ci avatar Oct 13 '22 10:10 connor-philip-ci

@connor-philip-ci Thanks for reporting the issue.

I tried to reproduce the issue mentioned. The first thing which I noticed in the issue is the version.

Do you have any specific need to keep the devspace yaml version at v1beta9? I assume you are using pipelines (create_deployments) which is the feature developed as part of v6 and pipelines use some constructs which were restructured(images, deployments, etc). As per my understanding, changing devspace yaml version to latest should do the trick.

bagulm123 avatar Oct 17 '22 10:10 bagulm123

@mahendrabagul

Do you have any specific need to keep the devspace yaml version at v1beta9?

This is a backward compatibility issue, In order to allow for a smoother upgrade, I was seeing if I could upgrade to devspace v6 (in order to prompt developers to upgrade and to upgrade the version on our tooling) before changing the files.

I assume you are using pipelines

I was not using pipelines as those features aren't available in v1beta9 as far as I know.

To summarise, the upgrade plan was:

  1. v5 & v1beta9
  2. v6 & v1beta9
  3. v6 & v2beta1

Doing it in this way means there would potentially be no point where errors would occur for other developers on the projects I work on.

connor-philip-ci avatar Oct 17 '22 11:10 connor-philip-ci

Hi @connor-philip-ci,

Would you mind posting the minimal devspace.yaml you have problems with? I tried a few examples with v1beta9 and devspace version 6 but It worked fine(may be, I didn't use the construct you have in your devspace.yaml)

bagulm123 avatar Oct 21 '22 09:10 bagulm123