Does modifying .gitpod.yml invalidate existing Gitpod prebuilds?

Gitpod workspaces use .gitpod.yml to define init tasks, ports, and workspace configuration, and prebuilds run initialization on push so later workspace starts can reuse completed steps. Prebuilds are associated with branches or pull requests rather than every ref automatically.

The unresolved behavior is whether editing .gitpod.yml invalidates existing prebuilds for a branch or pull request, or whether Gitpod reuses stale prebuild outputs until another trigger occurs. Current documentation does not establish exact cache invalidation rules, and behavior may differ between Gitpod cloud, self-hosted deployments, and subscription plans.

Because workspaces are ephemeral and uncommitted files outside the persisted workspace directory may be lost, prebuild reuse directly affects whether configuration changes take effect on the next workspace start.

Does Gitpod invalidate existing prebuilds when .gitpod.yml is modified on a tracked branch?

Which change to .gitpod.yml forces a prebuild rebuild versus reuse of cached outputs?

Does prebuild invalidation differ between Gitpod cloud and self-hosted installations?