You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The desktop release workflow (.github/workflows/realease-desktop-app.yml) can publish a GitHub Release that is missing assets for one or more platform/arch legs, and the incomplete release still goes fully live. When that happens:
macOS autoupdate breaks — update.electronjs.org/gridaco/grida/darwin-<arch> serves nothing for the missing arch, so installed apps on that arch can't update.
Download links 404 — the release-notes template (.github/release-notes/desktop.md) hardcodes per-arch asset URLs; a missing asset makes those links dead.
grida.co/downloads degrades to a stale fallback — downloads.ts's getLinks() throws when an expected asset is absent from the latest release, and getLinksForPage() then falls back to the hardcoded v0.0.1 links for all platforms.
What happened (v0.0.7)
Release run 28963031896 failed on exactly one leg: build (macos-apple-silicon, macos-26, arm64).
Cause: a transient Apple notarization 403 — Failed to notarize via notarytool … HTTP 403. A required agreement is missing or has expired. This was not the Intel dual-runner (ci(desktop): restore macOS Intel (x64) builds via native dual-runner (#947) #953): the x64 leg notarized successfully ~1 minute later on the same credentials, and the same arm64 job was green earlier the same day.
With fail-fast: false, the other three legs published a partial v0.0.7 (no Apple-Silicon .dmg/.zip).
Resolved by re-running the failed leg (gh run rerun 28963031896 --failed); arm64 assets, the darwin-arm64 autoupdate feed, and the download links are all healthy again.
Root cause
@electron-forge/publisher-github creates the release as a draft by default and never promotes it. The current workflow un-drafts it as a side effect of the "Update release notes" step, which is gated on the linux leg only. So the release goes live the moment linux finishes — regardless of whether the macOS/Windows legs succeeded. There is no "all legs present and all expected assets present" gate before the release becomes public.
Options (for later pickup)
1. Manual review gate (lightest). Keep the release as a draft and have a human review the asset list, then click Publish. Note: this is not possible today — the pipeline auto-publishes, there is no button to press. It requires a small change: set publisher draft: true explicitly and remove the auto-un-draft (the notes step). Prevention then relies on the releaser eyeballing the assets — which is the realistic, low-cost mitigation given how rare this is.
2. CI atomic gate (draft-until-complete). Fully automated:
prepare job pre-creates the draft pinned to the build SHA (gh release create v$VER --draft --target $SHA) so parallel legs reuse one draft.
build matrix uploads into the draft (unchanged, minus the notes step).
finalize job (needs: build, so unreachable if any leg fails) verifies the complete asset set, stamps notes, and promotes with gh release edit v$VER --draft=false.
A failed leg leaves an invisible draft — nothing public, no broken feed/links.
Asset criteria (per version $VER) either option should check before publishing:
(The .zip + RELEASES/.nupkg are the autoupdate-critical ones — Squirrel.Mac and Squirrel.Windows respectively.)
Priority
Low. Driven by transient Apple-notary / network flakes, so expect it to recur occasionally. Workaround until fixed: verify the release carries all assets above before treating it as done, and re-run failed legs (gh run rerun <run-id> --failed) if partial.
downloads.ts fallback fragility: a single missing asset in the latest release collapses all platforms to the deprecated v0.0.1 fallback (getLinks() is all-or-nothing). Either gate above prevents this from ever triggering; independently, the fallback could degrade per-asset instead of throwing.
Summary
The desktop release workflow (
.github/workflows/realease-desktop-app.yml) can publish a GitHub Release that is missing assets for one or more platform/arch legs, and the incomplete release still goes fully live. When that happens:update.electronjs.org/gridaco/grida/darwin-<arch>serves nothing for the missing arch, so installed apps on that arch can't update..github/release-notes/desktop.md) hardcodes per-arch asset URLs; a missing asset makes those links dead.downloads.ts'sgetLinks()throws when an expected asset is absent from the latest release, andgetLinksForPage()then falls back to the hardcoded v0.0.1 links for all platforms.What happened (v0.0.7)
28963031896failed on exactly one leg:build (macos-apple-silicon, macos-26, arm64).Failed to notarize via notarytool … HTTP 403. A required agreement is missing or has expired.This was not the Intel dual-runner (ci(desktop): restore macOS Intel (x64) builds via native dual-runner (#947) #953): the x64 leg notarized successfully ~1 minute later on the same credentials, and the same arm64 job was green earlier the same day.fail-fast: false, the other three legs published a partial v0.0.7 (no Apple-Silicon.dmg/.zip).gh run rerun 28963031896 --failed); arm64 assets, the darwin-arm64 autoupdate feed, and the download links are all healthy again.Root cause
@electron-forge/publisher-githubcreates the release as a draft by default and never promotes it. The current workflow un-drafts it as a side effect of the "Update release notes" step, which is gated on the linux leg only. So the release goes live the moment linux finishes — regardless of whether the macOS/Windows legs succeeded. There is no "all legs present and all expected assets present" gate before the release becomes public.Options (for later pickup)
1. Manual review gate (lightest). Keep the release as a draft and have a human review the asset list, then click Publish. Note: this is not possible today — the pipeline auto-publishes, there is no button to press. It requires a small change: set publisher
draft: trueexplicitly and remove the auto-un-draft (the notes step). Prevention then relies on the releaser eyeballing the assets — which is the realistic, low-cost mitigation given how rare this is.2. CI atomic gate (draft-until-complete). Fully automated:
preparejob pre-creates the draft pinned to the build SHA (gh release create v$VER --draft --target $SHA) so parallel legs reuse one draft.buildmatrix uploads into the draft (unchanged, minus the notes step).finalizejob (needs: build, so unreachable if any leg fails) verifies the complete asset set, stamps notes, and promotes withgh release edit v$VER --draft=false.Asset criteria (per version
$VER) either option should check before publishing:Grida-$VER-arm64.dmg,Grida-$VER-x64.dmg,Grida-darwin-arm64-$VER.zip,Grida-darwin-x64-$VER.zipGrida.Setup.$VER.x64.exe,co.grida.desktop.x64-$VER-full.nupkg,RELEASESgrida_$VER_amd64.deb,grida_$VER_arm64.deb,Grida-$VER-1.x86_64.rpm,Grida-$VER-1.arm64.rpm(The
.zip+RELEASES/.nupkgare the autoupdate-critical ones — Squirrel.Mac and Squirrel.Windows respectively.)Priority
Low. Driven by transient Apple-notary / network flakes, so expect it to recur occasionally. Workaround until fixed: verify the release carries all assets above before treating it as done, and re-run failed legs (
gh run rerun <run-id> --failed) if partial.Related
downloads.tsfallback fragility: a single missing asset in the latest release collapses all platforms to the deprecated v0.0.1 fallback (getLinks()is all-or-nothing). Either gate above prevents this from ever triggering; independently, the fallback could degrade per-asset instead of throwing.