Automattic / Automattic/harper
Preserve published release state when retrying artifact uploads
- Dominant language
- Rust
- Stars
- 15.4k
- Forks
- 627
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 106
Description
## Summary
This follow-up concerns a potential publication-state regression in the artifact-upload workflow. The [current `binaries.yml`](https://github.com/Automattic/harper/blob/d6f2c362a0cb00ea770e128d822cdb72b2c29337/.github/workflows/binaries.yml) still combines `allowUpdates: true` with `draft: true`, without `omitDraftDuringUpdate`.
## What happened
- August 30: #4256 reported the initially missing desktop artifacts.
- August 31: the desktop DMG became downloadable, allowing the nixpkgs updater to build 2.9.1 and open [NixOS/nixpkgs#558248](https://github.com/NixOS/nixpkgs/pull/558248).
- September 1, around 16:14 UTC: the release was no longer publicly accessible. REST returned `404` for `releases/tags/v2.9.1`, GraphQL returned `null`, and the DMG URL returned `404`. The `v2.9.1` Git tag still existed, but the latest-release APIs reported `v2.8.0` again.
- September 1, 19:25 UTC: this is the publication time now reported by the [restored release's metadata](https://api.github.com/repos/Automattic/harper/releases/tags/v2.9.1). Its desktop assets retain August 31 upload timestamps.
- September 2: the release and desktop artifacts are available again, and #4256 was closed after maintainer confirmation.
## Suggested change
The pinned `ncipollo/release-action` version documents [`omitDraftDuringUpdate`](https://github.com/ncipollo/release-action/tree/339a81892b84b4eeb0f6e744e4574d79d0d9b8dd#action-inputs), which defaults to `false`. With the current inputs, a late job or rerun can set an existing published release back to draft. Setting it to `true` preserves the existing publication state during updates while still allowing new releases to be created as drafts:
```yaml
with:
artifacts: ${{ matrix.platform.name }}
allowUpdates: true
draft: true
omitDraftDuringUpdate: true
```
Could this guard be added to the release-upload step, with other artifact uploaders checked for the same behavior? A useful regression check would confirm that both a late matrix job and a retry leave an already-published release public.
Longer term, a coordinated publish step could wait for all required artifacts, including the signed desktop build, before publishing the draft.
Contributor guide
Research direction
Open .github/workflows/binaries.yml and inspect the release-upload step, then check the other artifact uploaders for the same update behavior. Add the documented publication-state guard and verify that late matrix jobs or retries do not make an already-published release draft again, while new releases can still start as drafts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, release
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 76/100