Skip to content

feat: always version the runner group storage backend - #26

Draft
hllvc wants to merge 9 commits into
mainfrom
feat/storage-backend-versioning
Draft

hllvc wants to merge 9 commits into
mainfrom
feat/storage-backend-versioning

Conversation

@hllvc

@hllvc hllvc commented Oct 29, 2026

Copy link
Copy Markdown
Collaborator

Summary

The runner group storage backend holds the runners' state files, but neither the AWS nor the Azure runner group module turned on versioning, so an overwritten or deleted state file could not be recovered (the top-level README claimed versioning that did not exist). This makes versioning a fixed part of the storage backend on both clouds, with a retention setting for old versions, and lets a local or self-hosted frontend read logs and artifacts through extra CORS origins.

Changes

  • Versioning (AWS and Azure): always on for a bucket or storage account the module creates, with no option to turn it off. storage_backend_versioning.noncurrent_retention_days (default 365, 0 = keep forever) sets how long old versions are kept. A leftover enabled key in existing inputs is ignored.
  • AWS lifecycle: one lifecycle configuration expires noncurrent versions, cleans up expired delete markers and aborts incomplete multipart uploads after 7 days.
  • Azure lifecycle: a management policy deletes previous versions after the retention period. Azure counts a version's age from when it was written, not when it was replaced; the docs spell this out.
  • Azure tier: azure_storage.account_tier accepts only Standard. Premium (page-blob) accounts have no blob versioning, and azurerm 4.x could not manage them anyway (403 on the data plane during plan).
  • CORS: new storage_backend_cors_extra_origins adds origins next to the console origin (e.g. http://localhost:3000). Entries must be bare origins: no wildcard, path, query or fragment. Azure de-duplicates the list.
  • Existing storage: with create_storage_backend = false the module still leaves the bucket or account alone. A check block warns when extra CORS origins are set but cannot be applied, and the docs say to enable versioning on it yourself.
  • Template form: input_schema.json / ui_schema.json for both modules gain the retention and CORS fields; README and DOCUMENTATION cover the new behavior.

Testing

  • tofu test with mock providers: AWS 11 and Azure 10 cases (versioning always on, leftover enabled = false ignored, retention 0, existing storage, Premium rejected, CORS validation and de-duplication)
  • Real Azure apply in a demo subscription: versioning on, policy created, an overwritten blob kept its previous version; resources deleted afterwards
  • QA workflow running this branch (AWS, eu-north-1): versioning and the 365-day rule applied, CORS with http://localhost:3000 in place
  • Plan on the QA workflow after the last commit: only the multipart rule should be added

Risks

  • Existing deployments of either module get versioning turned on in place at their next apply. Old versions then accumulate up to the retention period, which adds storage cost.
  • Azure deployments that set account_tier = "Premium" now fail validation instead of failing at plan.

@hllvc hllvc self-assigned this Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant