Prebuild invalidation
Prebuilt workspaces will become stale if not claimed. Examples:
- A monorepo cloned during prebuild will fall behind its origin
- A new VM AMI or container image may release after a workspace was created
When defining a prebuild, the following syntax should configure a maximum lifetime for a prebuild, after which such an unclaimed prebuild must be deleted and replaced.
resource "coder_workspace_preset" "us-nix" {
name = "Nix US"
parameters = {
(data.coder_parameter.region.name) = "us-pittsburgh"
(data.coder_parameter.image_type.name) = "codercom/oss-dogfood-nix:latest"
}
# ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
prebuilds = {
instances = 2
cache_invalidation = {
# See the Invalidation section for more
invalidate_after_secs = 86400
}
autoscaling = {
... # See the Autoscaling section for examples
}
}
}
Furthermore, it should be possible to invalidate a prebuild using the API. This might already be possible by using the endpoint that deletes a workspace.
Furthermore, it should be possible to invalidate a prebuild using the API. This might already be possible by using the endpoint that deletes a workspace.
Initially, we considered manual prebuilt workspace invalidation only within the context of them becoming stale. However, invalidating a prebuilt workspace is mechanically no different from deleting it.
We've also received feedback to the effect that template administrators should be able to delete prebuilt workspaces for maintenance reasons.
As a result, it is clear that we should provide template administrators with:
- the ability to delete a prebuilt workspace
- this allows them to appropriately handle stale builds
- as well as to clean up failed builds
- this would look and feel identical to deleting any other workspace
- the ability to bulk delete all unclaimed prebuilt workspaces for a given preset or template version
- template administrators should not be able to delete workspaces for any other users, except for the prebuilds system user