devspace-sh / devspace

DevSpace - The Fastest Developer Tool for Kubernetes ⚡ Automate your deployment workflow with DevSpace and develop software directly inside Kubernetes.
https://devspace.sh
Apache License 2.0
4.22k stars 353 forks source link

Backwards compatibility issue with cross config variable references #2373

Open connor-philip-ci opened 1 year ago

connor-philip-ci commented 1 year ago

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:

Anything else we need to know?

/kind bug

mahendrabagul commented 1 year ago

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

connor-philip-ci commented 1 year ago

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

mahendrabagul commented 1 year ago

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)