Automattic / Automattic/harper

Preserve published release state when retrying artifact uploads

Open Beginner friendly
#4,282 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.