chore: consolidate and harden release workflows - #10447
Conversation
…chain includes cache already
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cc27a059c0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| name: internal-goose-${{ inputs.target }} | ||
| path: artifacts/internal-goose-${{ inputs.target }} | ||
| if-no-files-found: error | ||
| retention-days: 1 |
There was a problem hiding this comment.
Keep macOS signing input artifacts past approval delays
When signing is true, package-desktop does not start until the signing environment is approved, but this internal binary expires after the minimum 1-day retention window (actions/upload-artifact documents retention-days as the duration after which an artifact expires). If a tagged release waits more than a day for signing approval, the later download of internal-goose-${{ inputs.target }} fails and the signed macOS release cannot be packaged; use the default retention or a window that covers expected approval delays.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
1 day is enough based on previous release data
| name: internal-windows-unsigned${{ inputs.windows_variant == 'cuda' && '-cuda' || '' }} | ||
| path: ui/desktop/dist-windows/ | ||
| if-no-files-found: error | ||
| retention-days: 1 |
There was a problem hiding this comment.
Keep Windows signing artifacts past approval delays
For signed Windows releases, this unsigned distribution is uploaded before sign-desktop-windows waits on the signing environment, but it expires after only 1 day (actions/upload-artifact documents retention-days as the duration after which an artifact expires). If signing approval takes longer than that, the signing job cannot download internal-windows-unsigned... and the Windows release fails; use the default retention or a window that covers expected approval delays.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
1 day is enough based on previous release data
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 35ba958892
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| permissions: | ||
| contents: read |
There was a problem hiding this comment.
Grant OIDC permission to the Windows reusable workflow
When build-cli.yml is used by publish-npm.yml or the .build-cli PR comment workflow, this caller job limits the reusable workflow to contents: read, but .github/workflows/bundle-windows.yml declares permissions: id-token: write at the workflow level. GitHub validates reusable workflow permissions against the caller job, so the Windows CLI matrix is rejected before it builds even though signing and package_desktop are false; either allow id-token: write here or move the OIDC permission down to the signing job that actually needs it.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4858324c71
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| bundle-windows: | ||
| needs: [prepare-version] | ||
| uses: ./.github/workflows/bundle-desktop-windows.yml | ||
| uses: ./.github/workflows/bundle-windows.yml |
There was a problem hiding this comment.
Grant OIDC permission for Windows canaries
On pushes to main, this Windows reusable workflow is called from a workflow whose top-level permissions now only grant contents: read, while .github/workflows/bundle-windows.yml requests id-token: write at the workflow level. GitHub's reusable-workflow permissions can only be downgraded, not elevated, so the standard Windows canary job (and the CUDA call below) is rejected before its skipped signing path is considered; add id-token: write here or move the OIDC permission into the signing job.
Useful? React with 👍 / 👎.
Summary
Why
CLI archives and Desktop bundles use the same
goose-clibinary. This PR builds it once per macOS target and Windows variant, then reuses it for both packages—reducing duplicate work and keeping artifacts consistent.Change
Refactor the release automation so CLI and desktop artifacts share platform-specific build workflows while reducing duplication and tightening security.
scripts/set-cargo-version.shRelease workflow
flowchart TD R["release.yml"] --> L["build-cli-linux.yml<br/>Linux CLI"] R --> LD["bundle-desktop-linux.yml<br/>Linux Desktop"] R --> M["bundle-macos.yml<br/>ARM64 and x64"] R --> W["bundle-windows.yml<br/>Standard and CUDA"] R --> I["Install script"] M --> MB["Build goose-cli once per target"] MB --> MC["CLI archive"] MB --> MD["Desktop bundle"] W --> WB["Build goose-cli once per variant"] WB --> WC["CLI archive"] WB --> WD["Desktop bundle"] L --> P["Collect, attest, and publish artifacts"] LD --> P I --> P MC --> P MD --> P WC --> P WD --> PTesting
Created a branch named "release/pr-10447-test" and push the change to trigger release (without publish and sign) https://github.com/aaif-goose/goose/actions/runs/29479600721