decentraland / sites / 36880861222

94%

push

github

fix: give each deploy path its own concurrency group (#877)

* fix: give each deploy path its own concurrency group

One group for the whole workflow meant a release and a push could never run at
the same time, and GitHub keeps only one pending run per group: a release
waiting behind a push deploy was cancelled outright when the next push landed.
A cancelled run deploys nothing and reports no failure, which is the failure
this migration is most prone to.

Serialising them here was never what protected the KV record. The broker takes
a lease per environment and record before it writes, and answers
`rollout_in_progress` with a Retry-After that the action already treats as
retryable, so two deploys reaching the write at once resolve on their own.

Pushes keep a shared group, where a newer commit superseding a pending older
one is the wanted behaviour. Releases are keyed by tag and promotions by
environment, so neither can cancel the other.

* fix: describe the rollback this job can actually perform

The comment said a rollback needs the abandoned version set to 0%, "which this
single-version dispatch cannot express", and sent the reader to
set-rollout-manual.

Both halves are wrong. `percentage` accepts 0 in the action and in the broker,
so this job can zero a record. What one dispatch cannot do is name two versions,
and a rollback changes two: the abandoned version down to 0% and the one being
restored back to 100%. So it is this job twice, not a different workflow -- and
set-rollout-manual writes KV through the relay this replaces, outside the
broker's lease.

* fix: describe a rollback that actually restores the target

The previous wording said a rollback is two dispatches, the abandoned version
to 0% and the target to 100%. That holds only when exactly one record sits
above the target. Records are sorted descending by semver and the worker serves
the first whose percentage covers the user, so every version above the target
has to be zeroed -- on zon... (continued)

6074 of 6974 branches covered (87.09%)

Branch coverage included in aggregate %.

14666 of 15037 relevant lines covered (97.53%)

23.46 hits per line