fix(ci): match unversioned DMG names in Homebrew tap workflow - #992
webadderall merged 1 commit into
Conversation
The Update Homebrew Tap workflow downloaded the macOS release assets
with the patterns Recordly-*-arm64.dmg and Recordly-*-x64.dmg, which
assume a version segment in the filename.
electron-builder.json5 sets artifactName to "${productName}-${arch}.${ext}",
so the published assets are Recordly-arm64.dmg and Recordly-x64.dmg. The
wildcard requires a hyphen on both sides, so the patterns never matched
and "gh release download" exited with "no assets match the file pattern",
failing the job at the download step on every run.
Use the exact names the release publishes, matching the convention
already used in scripts/verify-macos-distribution.mjs.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📝 WalkthroughWalkthroughThe Homebrew tap workflow now downloads and checksums macOS release artifacts by using the exact filenames ChangesHomebrew artifact matching
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~5 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The workflow now downloads and checksums the published macOS artifacts correctly for both architectures. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Description
The
Update Homebrew Tapworkflow downloads the macOS release assets with these patterns:These assume a version segment in the filename. But
electron-builder.json5sets:so the published assets are
Recordly-arm64.dmgandRecordly-x64.dmg, with no version. The wildcard needs a hyphen on both sides, so it can never match. The same stale patterns are used again in thefindcalls of theCompute checksumsstep.Evidence
Every recorded run of the workflow has failed. The most recent one, run 34188339726 on the
v1.4.0release, failed at step 4Download release artifacts, with steps 5-9 skipped.Reproduced directly against the live release:
That checksum matches
SHA256SUMS.txtfrom thev1.4.0release exactly, so theCompute checksumsstep works once the download succeeds. I also confirmed the DMG assets are unversioned onv1.4.0,v1.3.3,v1.2.1andv1.1.14, so no release has ever matched.Change
Uses the exact names the release publishes, in both the download patterns and the
findcalls. This matches the convention already used for these artifacts inscripts/verify-macos-distribution.mjs, which hardcodes${productName}-${arch}.dmg. I kept the existing "Unable to locate macOS release artifacts" guard.Scope: this is the first blocker, not the whole fix
To be clear about what this does not do. Fixing the pattern gets the job past step 4, but I do not expect the workflow to succeed end to end yet, because
Clone tap repositoryshould fail next: neitherwebadderall/homebrew-tapnorwebadderallorg/homebrew-tapresolves for me via the API. The author of #541 reported the same thing. Creating or exposing the tap repo still looks necessary, and I cannot verifyHOMEBREW_TAP_TOKENfrom outside.I also could not execute the workflow itself, since it needs that secret and write access to the tap. The verification above is as far as I could get externally.
Related
Add homebrew install for mac): this is a likely reason it is still open, since the automation that would publish the cask cannot get past the download step.recordly.rbby hand. That is treating the symptom, and the cask goes stale again on the next release while this job keeps failing. I deliberately left that file and theTAP_REPOdefault alone here to avoid conflicting with that PR; this PR only touches the download and checksum steps.Question
The repo-root
recordly.rbdoes not appear to be referenced by any workflow, script or doc, and this workflow generates its own cask inline into the tap repo'sCasks/recordly.rb. Is the root file still intended to be maintained, or is it vestigial? Happy to open a follow-up either way.Testing Guide
gh release download v1.4.0 --repo webadderallorg/Recordly --pattern "Recordly-x64.dmg"succeeds; theRecordly-*-x64.dmgform returnsno assets match the file patternSHA256SUMS.txtnpm run lintandnpm test(1183 passing) clean, though this change is CI-onlyType of Change
Checklist
Summary by CodeRabbit