Skip to content

feat: deploy gating model — readonly prod + rollback, two-stage dev, PR gate - #460

Merged
saqibmanan merged 8 commits into
mainfrom
feat/deploy-gating-model
Sep 15, 2026
Merged

saqibmanan merged 8 commits into
mainfrom
feat/deploy-gating-model

Conversation

@saqibmanan

Copy link
Copy Markdown
Contributor

Deploy gating model for DataSpaceFrontend:

  • prod (main): previously no tests at all — a release was marked last-known-good straight after deploy. Now only the readonly allowlist runs against prod, then promote (marks .last_good) on pass or rollback (reverts the releases/ symlink) on failure.
  • dev merges: smoke first → functional (api + consumer) only if smoke passes → rollback on any failure. Provider functional runs report-only (flaky against dev, CivicDataSpace-test#79).
  • PR gate (pr-gate.yml): every PR into main runs the full suite against dev; provider reports separately and won't be a required check.
  • api_base_url is now explicit per branch — run-smoke's api job otherwise falls back to the dev API, which would have tested dev's backend while gating a prod deploy.

Uses CivicDataSpace-test's suite / only_provider inputs (#76, #78).

Prod had no tests at all: a release was marked last-known-good straight
after deploy. Now main runs only the readonly allowlist against prod and
promotes on pass or rolls back on failure; dev runs smoke, then
functional only if smoke passed. api_base_url is explicit per branch --
run-smoke's api job otherwise falls back to the dev API.
Provider functional tests fail at shifting points against dev (autosave
races, slow create flows), so gating on them would roll back dev deploys
spuriously. The gating functional stage and the PR gate now skip
provider; separate provider jobs run with only_provider and report,
without being a dependency of rollback/promote or a required check.
Finalize and rollback did not list the report-only provider job in needs,
so a deploy asked for finalize approval while provider tests were still
running. Both now wait for it, and condition on the gating jobs' results
explicitly instead of failure()/!failure(), which would count the
report-only job's result.
…pproval

production requires a reviewer, and every job referencing it asked again:
approve the deploy, then approve finalize or rollback -- so a failing prod
deploy stayed live until someone clicked. production-ops holds the same host
and SSH secrets with no reviewer and a main-only branch policy; the human
approval stays on the deploy job.
org_add_permission needs a Keycloak token to check canAdd. A called
workflow only sees secrets its caller passes, and the report-only job
passed none, so every org-create test skipped on both workers -- the
provider report looked green while never exercising org flows.
Same gap as the deploy workflow's report job: without it every
org-create test skips on both workers.
@saqibmanan
saqibmanan merged commit e110d31 into main Sep 15, 2026
3 of 6 checks passed
@saqibmanan saqibmanan self-assigned this Sep 16, 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