[werft] add with-dedicated-emulation switch

[AlexTugarev]

Description

This adds the initial step towards a setup mode trigger. The motivation is to provide a way for iterative work on Dedicated setups.

How to test

Trigger a new build of a preview env using werft from within a workspace. GH integration doesn't use the same version of /workspace/gitpod/.werft/jobs/build/job-config.ts, thus it wont work with the /werft comment.

 $ werft run github -j .werft/build.yaml -a with-preview=true -a with-clean-slate-deployment=true -a with-dedicated-emulation=true

The custom build should not contain any auth providers, thus they'd need to be created in the app.

Release Notes

NONE

Documentation

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-large-vm
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh

[werft-gitpod-dev-com]

started the job as gitpod-build-at-setup-mode.21 because the annotations in the pull request description changed
(with .werft/ from main)

[mads-hartmann]

Hey @AlexTugarev 👋 I'm a bit unclear about the direction this is going so I have a quick clarifying question before I can leave a proper review ☺️

I think what confuses me is that "with setup" will do "less setup" as it won't configure auth providers.

If this flag is used explicitly to handle cases related to Gitpod Dedicated, could we name it GITPOD_DEDICATED_ENABLED or something along those line to clearly communicate the intent?

If the intention is to have different "setup modes" - e.g. "dedicated" and "something else" and "another way of setting up things" - then I'd prefer we'd name the environment variable "GITPOD_SETUP_MODE" and then then agree on a set of value that can have (e.g. "standard", and "dedicated" to behind with)

Thanks!

[iQQBot]

I think what confuses me is that "with setup" will do "less setup" as it won't configure auth providers.

I think the setup means you need setup auth providers manual when you first connect this preview environment.

[AlexTugarev]

@mads-hartmann, sorry for the late response 🙏🏻

This PR was a first step made towards a preview environment that would mimic Dedicated installations. The WebApp team is working on a tasks which require proper testing with environments that as as close as possible to fresh Dedicated cells. At the same time it would be great to have the usual turnarounds as with preview envs.

I hope that provides some motivation for this PRs.

The scope of this PR was quite limited as we were just discussing about the semantics of the special setup mode we wanted to switch on using this option. In the meantime we agreed on setting up a setup service account in a post-deploy step, see #15657.

So, to sum up, the plan is to provide a special mode of a preview environment that would allow us to iterate faster on Dedicated task:

1. Provide with a switch for preview deployments to turn off the Git auth providers
2. Include setup account (disabled by default)
3. (setup mode = true) Enable the setup account

[AlexTugarev]

Thanks for the discussion on that, @mads-hartmann! I'll change the flag to with-dedicated-emulation in order to express its purpose.

✔️ done

[AlexTugarev]

/werft run

👍 started the job as gitpod-build-at-setup-mode.24
(with .werft/ from main)

[mads-hartmann]

Looks great, thanks @AlexTugarev! I added the hold label just so I can approve before CI passes. Could to update our docs to also list this flag? 🧡

[AlexTugarev]

/werft run

👍 started the job as gitpod-build-at-setup-mode.25
(with .werft/ from main)

[AlexTugarev]

/hold cancel