Fix propagation of PVC feature flag across prebuild/regular workspaces

[geropl]

Description

This ensures that:

• prebuilds follow the usePersistentVolumeClaim project setting
• on workspace start, persistent_volume_claim can be added (if user enabled that flag) but not removed (e.g. in case a prior instance had that feature-flag enabled)

:question: Is that what we want to achieve? :thinking: Synced with @sagor999 : yes :heavy_check_mark:

Related Issue(s)

Fixes #12718

How to test

Release Notes

NONE

Documentation

Werft options:

• [x] /werft with-preview
• [ ] /werft with-integration-tests=all Valid options are all, workspace, webapp, ide

[sagor999]

/hold to ensure we (workspace) team can test this prior to merge

[sagor999]

@geropl thank you for PR!! @jenting would you be able to take a peek at this PR and verify it as well?

[werft-gitpod-dev-com[bot]]

started the job as gitpod-build-gpl-12718-pvc.4 because the annotations in the pull request description changed (with .werft/ from main)

[werft-gitpod-dev-com[bot]]

started the job as gitpod-build-gpl-12718-pvc.5 because the annotations in the pull request description changed (with .werft/ from main)

[werft-gitpod-dev-com[bot]]

started the job as gitpod-build-gpl-12718-pvc.6 because the annotations in the pull request description changed (with .werft/ from main)

[werft-gitpod-dev-com[bot]]

started the job as gitpod-build-gpl-12718-pvc.7 because the annotations in the pull request description changed (with .werft/ from main)

[jenting]

Hmmm... I started to test this scenario but failed

• Project without PVC
• User A with PVC
• User B without PVC

1. User A creates a new branch X and pushes a commit
2. The prebuild is built with PVC ❌ (which is wrong, since project does not have PVC enabled, so it took user's flag instead).
3. The user B opens the prebuild with branch X, the workspace opens with PVC object ❌ (which is not correct, but due to failure at step 2.)

cc @geropl

[geropl]

Thank you @jenting , especially for the details, so I know what to look for. :thinking: Let me see if I find time to look into it today.

[jenting]

Thank you @jenting , especially for the details, so I know what to look for. 🤔 Let me see if I find time to look into it today.

Just for the heads up, I did not run the full PVC + prebuild test cases manually for this PR. I plan to add more integration tests so we can verify it easily.

[werft-gitpod-dev-com[bot]]

started the job as gitpod-build-gpl-12718-pvc.9 because the annotations in the pull request description changed (with .werft/ from main)

[sagor999]

@jenting can you try again? ^

[jenting]

@jenting can you try again? ^

I am testing it now 😄

[jenting]

/werft run with-preview

:+1: started the job as gitpod-build-gpl-12718-pvc.10 (with .werft/ from main)

[jenting]

/werft run with-clean-slate-deployment

:+1: started the job as gitpod-build-gpl-12718-pvc.11 (with .werft/ from main)

[jenting]

I have verified all the cases, one case failed.

The prebuild project does not enable persistent_volume_claim, but user A enables persistent_volume_claim. The prebuild project was built without a PVC object, this is good. 👍 User A opens the workspace from prebuild. The workspace does not open with a PVC object. This is wrong because the user enables persistent_volume_claim. ❌

---

Let me summarize the behavior we expected. cc @geropl

• The prebuild project does not enable persistent_volume_claim. The prebuild pod runs without a PVC object.
  • The user opens the workspace from the prebuild project:
    • If the user with PVC, the workspace opens with a PVC object.
    • If the user is without PVC, the workspace opens without a PVC object.
• The prebuild project enables persistent_volume_claim. The prebuild pod runs with a PVC object.
  • The user opens the workspace from the prebuild project:
    • If the user with PVC, the workspace opens with a PVC object.
    • If the user is without PVC, the workspace opens with a PVC object.

[geropl]

@jenting Thank for you diligent testing! :pray: Would have loved to do that myself, but seem to be short on time :upside_down_face:

[geropl]

/hold

[geropl]

/unhold