decentraland / sites / 36722799338

94%

push

github

feat: publish a release to zone instead of staging it (#874)

* feat: publish a release to zone and today instead of staging it

Cutting a release uploaded the bytes under the tag and touched no KV record, so
nothing served it until someone remembered to dispatch a promotion. It could
not have done more as written: the job declared no `environment:`, GitHub
therefore issued no environment claim, and the broker refuses `today` without
one. The empty list made that explicit rather than a failure.

Declaring `environment: today` supplies the claim, and one job covers both
targets — `zone` requires no claim at all, `today` requires one naming itself.
Verified against the broker's own publication policy with the token shape this
job will actually carry: zone accepted, today accepted, org refused with
`EnvironmentApprovalRequiredError`.

`org` stays out deliberately. The broker would take it — the version is a tag,
so the release requirement is satisfied — but production is promoted by hand,
naming the version, from the `promote` job.

The consequence worth stating: GitHub evaluates `environment:` BEFORE the job
starts, so once `today` has required reviewers, publishing a release waits for
one instead of deploying. That is the gate working rather than a regression,
but it changes what cutting a release feels like. Until those rules exist it
deploys immediately, with no approval — which is the argument for setting them.

Renamed from `stage-release`, which described what it no longer does. Nothing
referenced the id: master's ruleset declares no required status checks, only
deletion, non-fast-forward, pull-request and signature rules.

* fix: keep prereleases out of the release rollout

`release: published` fires for prereleases as well, so without a guard an RC
would publish to zone and today like any other release. No prerelease appears
in the last 30 releases, so this costs nothing today and prevents a surprise
the first time someone cuts one.

* fix: publ... (continued)

6074 of 6974 branches covered (87.09%)

Branch coverage included in aggregate %.

14665 of 15036 relevant lines covered (97.53%)

23.46 hits per line