Repository navigation
ci(release): publish a signed Intel macOS DMG - #1825
Conversation
kalvinnchau
left a comment
There was a problem hiding this comment.
🤖 Two release compatibility findings; details inline.
eb44153 to
59b15f1
Compare
wesbillman
left a comment
There was a problem hiding this comment.
🤖 Star Lord’s automated source review via Wes’s account.
- P1: The existing Hermit/rustup finding remains applicable. At this head, the affected compilation is now
buzz-agent-command; the outer target-library check still does not cover the nested compiler. Preserve an absolute rustup compiler selection through the command chain and validate that path. - PR material: Correct the 10.15 minimum-OS claim and distinguish historical validation from this revision. The unchanged Tauri configuration requires macOS 12.0, and the bundled Goose pin is now 1.57.0.
- Optional docs:
docs/releases.md:66–68should distinguish arm64 verification at promotion from both macOS architectures’ build-time checks.
Rocket, Mantis and Groot completed independent lanes. Head 59b15f118f6383c52601b3baabdeb7a98d82696f; base e210c8a472cc49ee7c0b49b62bfad10fd5ef4c8e. Source-only: no builds/tests or app execution. Required CI passed in the snapshot; signed Intel packaging, install/update behavior and release-job cost remain unverified.
59b15f1 to
517c523
Compare
wesbillman
left a comment
There was a problem hiding this comment.
🤖 Star Lord’s automated source follow-up via Wes’s account.
The earlier compiler-selection P1 is repaired in source: bin/cargo and bin/rustc now use rustup proxies, rust-toolchain.toml pins 1.98.1, and the Intel workflow installs that toolchain’s target library before the nested helper build. No new production defect found in this follow-up.
The previous PR-material correction remains open: the description still claims a 10.15 minimum and Goose 1.56.0 validation, while this revision requires macOS 12.0 and pins Goose 1.57.0. Update the supported-OS statement and label historical build/test evidence with its actual revision. The previously noted promotion-verification wording remains optional.
Head 517c523bc97bfafd208999ca56b71490a920e100; base a060691e9a09923249ee40051d9dba979fb633bd. Rocket, Mantis and Groot completed independent lanes. Source-only: no builds, tests or app execution. Current-head CI required passed in the snapshot; signed Intel packaging, hardware install/update acceptance and release-job timing/cost remain unverified. This is a COMMENT review, not approval.
These are the CI-configuration items of the 23-30 Oct CI flake sweep note: section 5 (WebKit shards near the 15-minute cap), section 12 (the JavaScript lane near its 10-minute cap), and from sections 15 and 16 the native-fixture retention, a `gh release create` retry and a bounded, retried Hermit fetch. The apple-codesign-action poll belongs to another repository and is left out. Both job caps are unchanged. Before editing, I re-checked origin/main (8fdb02d): no commit since this branch's base touches .github/. Open PRs #1875, #1825, #1838, #873, covers any item here, so nothing was dropped. #1825 rewrites the publish step's --notes line, so whichever lands second resolves a small indentation conflict there. Check names: the rulesets on main require only "CI required" and "DCO Check". The CI required job reads needs.javascript.result and needs.browser.result, which aggregate every matrix entry, so no rule depends on a per-shard name. The only tag ruleset covers desktop-v*. I therefore changed shard counts rather than using weights. PWTEST_SHARD_WEIGHTS exists in Playwright 1.63, but it is undocumented internal plumbing. It takes integer weights over test counts and needs re-tuning whenever files move. A first hand-tuned 12-way vector only moved the peak (summed 1256 s to 1228 s). Splitting slow files would not place them either: Playwright cuts contiguous blocks by test count, and Vitest assigns files by path hash. Method: per-test durations are medians over the WebKit and Vitest reports of four green main runs (40996275711, 41001954087, 41004128008, 41005004728). For each candidate total, Playwright's own --list on this checkout gives shard membership; it reproduced main's 5/12 file set exactly. For Vitest, a copy of 5.0.4's hash-sorted equal-count split reproduced main's 3-way split, apart from files added between those runs. Playwright elapsed is about 1.11 x summed test time / 2 workers on every WebKit shard. Job timings cover 887 CI runs from 10-28 16:10 to 10-30 05:16 UTC. WebKit journeys: 12 -> 14 shards (section 5) - CI: the cap cancelled WebKit 7 times on 10-28 between 16:38 and 20:38 UTC (9/12 in 40728598560, 40751414448 twice, 40753322020, 40755908393 and 40764944582; 8/12 in 40727796862), and not since. Since 20:30, 9/12 still runs p50 12.2, p90 13.1, max 14.9 min. Over the window, 1/12 runs p90 13.6 and max 14.4 min. - Cause: contiguous equal-count blocks put slow files together. Today 8/12 and 9/12 sum 1256 s and 1231 s of test time against a 906 s mean. - Change: fourteen WebKit shards; Chromium keeps nine. The docs give the new counts. - Before, observed medians per shard 1..12 (Playwright elapsed / summed test time, s): 519/964 578/1110 501/901 593/1098 343/642 454/770 486/751 680/1269 680/1255 344/575 412/734 471/839. - After, projected per shard 1..14: 506/909 463/832 508/913 463/833 457/822 308/553 358/644 401/722 546/982 565/1015 482/867 226/407 305/548 462/830. The slowest shard drops from 698 s to 565 s projected (-19%). For comparison, 13 shards reach 1138 s summed at most, 15 reach 1029 s (no gain over 14) and 16 reach 947 s. - Cost: summed test time is unchanged (about 10.9 ks per run). Two more jobs add about a minute each of container start, setup and fixture download. - Verified: browser-ci.test.mjs expands the new matrix and lists every shard through the workflow's own command. All 14 WebKit shards select tests (59-87 each), and the Linux shards plus macOS cover full discovery exactly once. - Hosted CI only: real per-shard wall times, and whether slow runners' tails shrink in proportion (the 13.1-14.9 min tails would scale to about 11-12.3 min). JavaScript: 3 -> 4 shards (section 12) - CI: 1/3 runs p50 7.8, p90 9.0, p99 9.4, max 9.7 min. 2/3 hit the cap once, in run 40974792053 (10-29 23:41), on a runner about 1.5x slower than usual. - Cause: setup, Biome, TypeScript and the build take 44-74 s; Vitest is the rest. 1/3 draws both of the slowest files by hash: MessageComposer.test.tsx (105 s) and InboxPage.test.tsx (105 s). - Change: four shards in the name, matrix and --shard argument. The docs give the new count. - Before, observed Vitest step medians: 475, 413 and 424 s (summed file time 697, 557 and 580 s). - After, projected: 330, 293, 358 and 271 s (summed 483, 430, 524 and 397 s). The two slow files land in different shards, and the slowest step drops by about 117 s (-25%). The simulation underestimated the current 2/3 and 3/3 by about 8%. - Cost: one more job of up to 75 s of fixed work. - Remaining gap: on a runner 1.5x slower, the slowest shard would still take about 10.8 min. Five shards (projected maximum 288 s) would be the next step if that recurs. - Hosted CI only: the real per-shard times. Native browser fixture retention: 1 -> 7 days (section 16) - CI: run 39869150645 (created 10-22) was re-run on 10-28. Its WebKit 9/12 job 123166139127 failed with "Unable to download artifact(s): None of the provided artifact IDs were found". The sweep counted two such failures, both re-runs more than 24 h later. - Cause: re-running failed jobs does not re-run the successful fixture job. The shards download the original attempt's artifact by ID, and it had expired after one day. - Change: seven days, the same as every other artifact in ci.yml. The contribution docs say failed shards can be re-run in that window. - Cost: the tar is about 36 MB per run, now kept 7 days instead of 1. - Hosted CI only: a re-run of a failed shard 1-7 days later. Preview publish retry (section 15) - CI: Desktop previews run 40336779380 (10-26), job 121631685286. After 16 s of uploads, gh got "HTTP 500 (https://github.com/proxy/api.github.com/repos/block/buzz-app/releases/424352244)" from the call that publishes the uploaded draft, then removed its draft. v0.7.0-preview.172.1 does not exist. That is 1 of 56 runs in the sweep. - Change: up to three tries, waiting 15 s, then 30 s. After a failed try, `gh release view "v$VERSION" --json isDraft` decides the cleanup. A draft is deleted (`gh release delete "v$VERSION" --yes || true`); it was never published, so the feed cannot point at it. A published v$VERSION is never deleted: on a publish-only re-run it is an earlier attempt's release, possibly already promoted. The step reports it and exits 1, as that re-run failed before this change. If nothing is found, the step just tries again. A tag that a failed publish created is left in place: it can only point at SOURCE_SHA, and GitHub uses an existing tag rather than --target. The 5-minute job cap stays: three 16 s tries and 45 s of waits fit. - Verified: desktop-release.test.mjs runs the real step with a fake gh and sleep. Success on the first try makes one call. Two failures that leave nothing succeed after create, view, sleep 15, create, view, sleep 30, create. A draft left by a failed try is deleted before the next try, which runs even if that delete fails. Three failures exit 1 with no view after the last. A published release stops the step after create and view, with exit 1 and no delete. Against HEAD's step, the test fails with status 1 after a single create. A step that deleted v$VERSION without checking isDraft fails the published case: it deletes the release twice. - Hosted CI only: GitHub's real responses, and that gh finds a leftover draft by tag. Bounded, retried Hermit fetch (section 16) - CI: on 10-28, between 04:18 and 05:22 and between 10:19 and 14:24 UTC, the first ./bin/node call stalled while fetching nodejs.org's tarball. In 97 jobs it held the step until the job cap; for example, JavaScript 1/3 job 122871430903 sat 10 min in "Verify pinned tool entry points". 7 more exited 101; for example, WebKit 10/12 job 122852465599 failed after 8 min 47 s with "fatal:hermit: https://nodejs.org/dist/v24.18.0/node-v24.18.0-linux-x64.tar.gz is unavailable: unexpected EOF". - Change: the new scripts/ci-retry.sh runs a command up to TRIES times and ends any try that outlasts SECONDS. Setup runs ./bin/node --version and ./bin/pnpm --version through `scripts/ci-retry.sh 3 120`. perl supervises each try because macOS runners lack timeout(1). A perl alarm followed by exec would not work: Hermit is a Go program, which ignores SIGALRM. Each try runs in its own process group. At the deadline the group gets TERM, then KILL once the command exits or 5 s pass, whichever comes first, so a grandchild that ignores TERM cannot outlive its try. A timed-out try exits 124, like timeout(1); the last try's status is kept; and each retry emits a ::warning:: annotation. A cold fetch normally takes about 2 s for node and 1.5 s for pnpm on Linux, and 6.5 s for both on macOS (run 40939349480, after #1871 changed bin/). - Verified: browser-ci.test.mjs pins both setup lines and drives the script with a scripted fake fetch: fail, then a stall whose grandchild holds the output pipes, then success; three failures keep exit 101; a try that ignores TERM ends with 124; a command that exits on TERM while its grandchild ignores it ends with 124 and leaves nothing running; and bad arguments exit 2. The test fails (spawnSync ETIMEDOUT) if the kill targets only the direct child, if the KILL step is removed, or if KILL is skipped once the command has exited. All scenarios pass under macOS /bin/bash 3.2. All but the grandchild one also passed in the pinned Playwright image (arm64 locally; perl 5.38.2, bash 5.2.21); that one has not run there. - Hosted CI only: whether a fresh connection gets through during an outage like 10-28's. If every connection stalls, the step now fails after about 6 minutes instead of at the job cap. Also whether Hermit leaves no partial package after TERM. Checks: actionlint 1.7.12 (Docker) on ci.yml and release.yml reports only three shellcheck infos, the same three it reports on HEAD. shellcheck 0.11.0 reports nothing on scripts/ci-retry.sh. Biome passes on both test files. node --test passes 21/21 on browser-ci, desktop-release, packaging and preview-feed (macOS only). Not pushed; hosted CI has not run on this commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>
517c523 to
f05148d
Compare
wesbillman
left a comment
There was a problem hiding this comment.
🤖 Star Lord’s automated source follow-up via Wes’s account.
One new P1 rebase-integration defect is recorded inline. The previous rustup compiler-selection repair remains intact in source.
The existing PR-material correction remains open: the description claims a macOS 10.15 minimum, while this revision requires 12.0, and its Goose 1.56.0/build evidence predates the current Goose 1.57.0 pin and bundled CLI. Correct the supported-OS statement and identify the revision used for each historical validation claim. The full integration-suite bullet already names its older revision.
Rocket, Mantis and Groot completed independent review lanes. Reviewed head f05148d34443bb6c70b19cddb03db7c177ff92a1 against base e7ae7b18cff03f371382ae60fc1064b60a667ed2, including the rebase from previously reviewed 517c523bc97bfafd208999ca56b71490a920e100.
Source-only: no builds, tests or app execution. Hosted CI required passed in the single snapshot; it does not exercise the signed Intel release path. Signed packaging, Intel install/update behavior, Rosetta-dependent CLI smoke execution and release-job timing/cost remain unverified. Public description and commit inspected; no attached images. This is a COMMENT review, not approval.
wesbillman
left a comment
There was a problem hiding this comment.
🤖 Star Lord’s automated source follow-up via Wes’s account.
No actionable findings in this follow-up. The prior Intel release blocker is repaired: .github/workflows/release.yml:163 checks the bundled CLI against $LIPO_ARCH, matching the matrix and the other bundled binaries. tests/integration/packaging.test.mjs:132–149 covers the per-leg checks. The PR description now correctly states macOS 12.0 and separates current validation from older build evidence; the release documentation also distinguishes per-leg build checks from Apple Silicon promotion checks.
Rocket, Mantis and Groot completed independent review lanes; Star Lord integrated the result. Reviewed head 35071085d7a28158cbf416b3e064d9d60b94ab00, base e7ae7b18cff03f371382ae60fc1064b60a667ed2, limited to prior findings and defects introduced by the three-file change since f05148d34443bb6c70b19cddb03db7c177ff92a1. Public PR description inspected; no attached images.
Source-only: no tests, builds or app execution. Hosted CI required passed in a single snapshot, but it does not validate signed Intel packaging, Rosetta-dependent CLI execution, Intel install/update behavior or release-job timing/cost. Those remain unverified. This is a COMMENT review, not approval.
Build the macOS preview job as an aarch64/x64 matrix. The Intel leg cross-compiles x86_64-apple-darwin on the Apple Silicon runner with the pinned Rust release from rustup, since Hermit's Rust ships only the host standard library. Both legs are signed, notarized and verified, and the preview feed gains a darwin-x86_64 updater entry. Co-authored-by: Jitter <2b2e6415e748c35180847a37aadae06a11e30dddc76b784e7fd9354c4eb42e7a@buzz.block.builderlab.xyz> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>
Verify release DMG still required the bundled buzz CLI to be arm64. On the Intel leg the CLI is x86_64, so verification would fail there and, since publish needs both macOS legs, block the whole preview release. Compare it with the leg's $LIPO_ARCH, as the app and other helpers already are. The packaging test now asserts that every Mach-O check in that step uses $LIPO_ARCH, bound to matrix.lipo, with no hard-coded architecture. Reword the x64 Rust step's comment: since #1871 Hermit's rustup proxies select the rust-toolchain.toml release, and the step adds the Intel standard library to that toolchain. Behaviour is unchanged. Correct the same claim in docs/releases.md, and state that the build job checks the updater configuration in both macOS binaries while promotion rechecks only the Apple Silicon one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>
3507108 to
fb6ea77
Compare
…able-page * origin/main: feat(browser): show a refused Builderlab app as a page in the panel (#2680) fix(profiles): cache profiles on disk and keep dm partners through eviction (#2178) feat(profiles): let each reader show verified people by username or full name (#2356) fix(media): show transparent avatars without a black background (#2477) fix(channels): keep the reader's place when Back returns to a link-opened channel (#2500) BUZZ-518: Explain required community sign-in (#2710) feat(desktop): serve credentials to agents and your CLI, with pairing (#2260) test(solo): wait for search and access before Share focus reveal (#2573) fix(relay): answer bytes a failed spool wrote; deflake the memory read (#1970) ci(release): publish a signed Intel macOS DMG (#1825) Signed-off-by: Nathan Thillairajah <nthillairajah@squareup.com> # Conflicts: # docs/browser.md # src-tauri/src/browser/builderlab.rs # src/features/browser/BrowserHostView.test.tsx # src/features/browser/BrowserHostView.tsx # src/features/browser/platform.test.ts
Summary
Publishes a signed, notarized Intel macOS DMG (
Buzz_<version>_x64.dmg) and updater archive next to the Apple Silicon one in every desktop preview. Intel installs also get adarwin-x86_64entry in the preview updater feed. Buzz 0.X shipped an Intel build (block/buzzrelease-macos-x64), but buzz-app only had the arm64 job, so Intel users (e.g. 2020/2021 Intel Macs) had nothing to install.release.yml: the macOSbuildjob is now a matrix overaarch64-apple-darwin/x86_64-apple-darwin. Both legs build with--target, sign and notarize through the same action, and check that the app executable,goose-acp,buzz-agent-commandand the bundledbuzzCLI match the leg's architecture ($LIPO_ARCH, frommatrix.lipo).publishverifies and assembles both macOS artifacts.promote_previewdownloads and verifies the x64 updater archive too.buzz-foundationexecutable fallback in promotion is gone: no preview with that name can be promoted any more, because none has an x64 archive.rustcandcargoare rustup proxies that select therust-toolchain.tomlrelease (1.98.1), including in nested builds started through the pnpm/node shims. That toolchain has only the host's (arm64) standard library, so the x64 leg adds thex86_64-apple-darwinstandard library to the same toolchain with rustup.scripts/preview-feed.mjsandscripts/prune-preview-releases.mjsgaindarwin-x86_64→Buzz_<version>_x64.app.tar.gz.tauri.conf.json. Both DMGs use main'sbundle.macOS.minimumSystemVersionof12.0(set in build: stage pinned upstream goose-acp releases #1864), so Intel Macs need macOS 12 or later.docs/releases.mdnow list the Intel DMG.docs/releases.mdalso says that the build job checks the updater configuration in both macOS binaries, while promotion rechecks only the Apple Silicon one.Validation
This revision (
35071085d, basee7ae7b18c):node --testpasses fordesktop-release,preview-feed,prune-preview-releasesandpackaging(22/22).desktop-releasechecks that a missing Intel artifact blocks publication. The packaging test covers the matrix and--target, and asserts thatVerify release DMGchecks the app,goose-acp,buzz-agent-commandand thebuzzCLI against$LIPO_ARCHwith no hard-coded architecture. Replaying that last assertion against the previous head (f05148d34) flags its arm64-only CLI check.Earlier revision (
eb441539, base10039529), not rerun since. At that revision goose-acp was built from source (122834086) rather than the current pinned 1.57.0 release, the app didn't bundle thebuzzCLI yet (#2027), and Hermit's Rust wasn't yet rustup (#1871).pnpm tauri build --ci --no-sign --bundles dmg --target x86_64-apple-darwin, Rust 1.98.1 plus the official x86_64 std) producedBuzz_0.7.0_x64.dmg(35 MiB).lipo -archsshowedx86_64forBuzz,goose-acpandbuzz-agent-command, and none of them linked non-system libraries.goose-acp --versionprintedgoose-acp 1.56.0, andbuzz-agent-commandgave its expected usage error. I didn't launch the app itself, so my installed Buzz profile wasn't touched.node --testpassed for the same four files (21/21). The fullnode --test tests/integration/*.test.mjsrun gave 228/229. The one failure,macOS launchers preserve icon…inworktree-icon.test.mjs, failed the same way on a cleanorigin/main(10039529).Not yet validated / rollout notes
main, so the first scheduled run after merge is the first real signed Intel build. That includes the x64 leg'sbuzz --helpsmoke check, which needs Rosetta to run the Intel CLI on the Apple Silicon runner. Candidate-only runs don't build macOS.🤖 Generated with Claude Code