Make sure dashboard is deployed after server and public api server

[mustard-mh]

Description

To make sure dashboard is deployed after server and public api server

• 👎 Every time server or public-api-server deployed a new version, dashboard will restart. But it's not harmful for dashboard.
• 👎 We can not manually change server or public-api-server 's image anymore. Everything that deployed should be built from installer

Summary generated by Copilot

### 🤖 Generated by Copilot at d93f3fa

This pull request adds a new service-waiter package and command that waits for the server and public-api-server components to be ready before starting the dashboard component. It also adds a new service account and role for the dashboard component, and updates the constants and deployments of the dashboard and public-api-server components accordingly.

Related Issue(s)

Fixes EXP-822

How to test

• Open PR with Gitpod
• Check logs of dashboard pod container server-waiter and public-api-server-waiter, they should be succeed and dashboard should be accessable
• --image of dashboard initContainer should be the same with server and public-api-server 's image.
• Change deployment/server's image i.e. eu.gcr.io/gitpod-core-dev/build/server:main-gha.19119, restart dashboard, it should failed. (remember to undo server changes)

# change server
export KUBE_EDITOR='code --wait'
kubectl edit deployment/server

# restart dashboard
kubectl rollout restart deploy/dashboard

# check logs of service waiter if you want
kubectl logs -f pod/<dashboard_tab_tab_tab> -c server-waiter

# undo server
kubectl rollout undo deploy/server

---

✅ Test result share

Waiter started and works	Incorrect server image dashboard will not restart with health status	Undo server changes dashboard will ready

Documentation

Preview status

Gitpod was successfully deployed to your preview environment.

• 🏷️ Name - hw-service-waiter
• 🔗 URL - hw-service-waiter.preview.gitpod-dev.com/workspaces.
• 📚 Documentation - See our internal documentation for information on how to interact with your preview environment.
• 📦 Version - hw-service-waiter-gha.19146
• 🗒️ Logs - GCP Logs Explorer

Build Options

Build

• /werft with-werft
  Run the build with werft instead of GHA
• leeway-no-cache
• /werft no-test
  Run Leeway with --dont-test

Publish

• /werft publish-to-npm
• /werft publish-to-jb-marketplace

Installer

• analytics=segment
• with-dedicated-emulation
• workspace-feature-flags
  Add desired feature flags to the end of the line above, space separated

Preview Environment / Integration Tests

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-large-vm
• /werft with-gce-vm
  If enabled this will create the environment on GCE infra
• with-integration-tests=all
  Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh. If enabled, with-preview and with-large-vm will be enabled.
• with-monitoring

/hold

[geropl]

I'm not sure I understand this line: AFAIK with this approach, yes, we will leak resources (which is a more general problem), but the rollout should work, no? 🤔

[mustard-mh]

@geropl We just need a new name, we use Component as it's name before with xxx-restricted-root-user as its role (which its actual role was deleted in previous PR but not delete this role bind)

• Change RoleRef is not allowed for k8s
• When we use APIs, it will check the bind roles, then find that xxx-restricted-root-user not exists, so we need to delete old one

[mustard-mh]

• we will leak resources : no
• rollout should work: yes

[geropl]

Cool!

[akosyakov]

/gh run recreate-vm=true

[mustard-mh]

Remove --image flag

Dashboard started

[mustard-mh]

Let's hold until Monday

[akosyakov]

I only looked at the code and did not try.