add buildkite pipeline for cli release#71
Draft
mokagio wants to merge 7 commits intoainfra-2351-sign-and-notarize-imessage-cli-in-ci-localfrom
Draft
add buildkite pipeline for cli release#71mokagio wants to merge 7 commits intoainfra-2351-sign-and-notarize-imessage-cli-in-ci-localfrom
mokagio wants to merge 7 commits intoainfra-2351-sign-and-notarize-imessage-cli-in-ci-localfrom
Conversation
Wires the `platform-imessage` Buildkite pipeline (provisioned via [Automattic/buildkite-ci#848](Automattic/buildkite-ci#848)) to actually do something, so the macOS CLI release can move off GitHub Actions and onto Automattic Buildkite — keeping the Developer ID p12 and ASC API key alongside the rest of the org's Apple distribution material in `a8c-secrets` rather than as GitHub-side secrets. Trigger model: - PR / `main` push → compile-check only (`swift build -c release`). - `v*` tag push → `.buildkite/commands/release-cli.sh` runs the local `scripts/sign-and-notarize-cli` (universal binary, hardened runtime, Apple-notarized) and publishes the tarball + sha256 to a GitHub Release via `gh`. The release script is idempotent: if the release already exists for the tag it just uploads with `--clobber`, so re-runs from a Buildkite retry don't error. `shared-pipeline-vars` mirrors the convention from `pocket-casts-desktop` / `Automattic-Tracks-iOS`: pin the `a8c-ci-toolkit` plugin and read the Xcode image id from `.xcode-version`. Follow-up: once a tag build proves green end-to-end on Buildkite, remove `.github/workflows/release-imessage-cli.yml` so we don't have two workflows publishing different assets to the same release. --- Generated with the help of Claude Code, https://claude.ai/code Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
`artifact_paths` runs at end-of-step regardless of step exit code, so an explicit `buildkite-agent artifact upload` in the script only fires on success — exactly when we need the artifact least. Switching to the pipeline DSL means we still get the tarball + sha256 stashed even when codesign, notarize, or `gh release` fails partway through. The script now writes to `dist/` (already gitignored) instead of a mktemp dir, so the glob in `artifact_paths` has a stable target. --- Generated with the help of Claude Code, https://claude.ai/code Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collapse the two pipeline steps into one that runs on every CI build
(PR, `main`, tag) and produces a signed+notarized universal-binary
tarball, uploaded as a Buildkite artifact via `artifact_paths`. Non-tag
builds skip the `gh release` step; tag builds do the full publish.
Lets reviewers grab a fully usable CLI from any PR's BK build instead
of having to clone and run the script themselves.
Non-tag asset names are versioned `${package.json version}-${shortsha}`
so each build's artifact is uniquely named, matching the BK artifact
naming convention.
Tradeoff: every PR/`main` push hits Apple's notary service (~30-90s
each). Well under the 75/hr/team cap, but worth knowing if traffic
spikes.
---
Generated with the help of Claude Code, https://claude.ai/code
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Buildkite Mac agent doesn't carry our Developer ID cert in its keychain by default, so without this the script fails with `no Developer ID Application identity for team PZYM8XX95Q in keychain`. `set_up_signing` lane mirrors the `snelectron` / `matticspace-mobile` pattern: `sync_code_signing(type: 'developer_id', ...)` against the shared `a8c-fastlane-match` S3 bucket. Cert is already provisioned there for our team. `app_identifier: []` works for `developer_id` since the cert isn't tied to a specific app bundle. Env-var presence is enforced via release-toolkit's `EnvManager` so we fail fast with a clear message if `MATCH_S3_*` / `MATCH_PASSWORD` are missing on the agent, rather than getting an opaque `match` error. `Gemfile` carries only the two top-level gems (fastlane, wpmreleasetoolkit); everything else is transitive. --- Generated with the help of Claude Code, https://claude.ai/code Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CI expects it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale
Stacked on top of #70 (the local sign+notarize automation).
Adds the
.buildkite/files that wire the newplatform-imessageBuildkite pipeline (provisioned via Automattic/buildkite-ci#848) to actually do something — moving the macOS CLI release off GitHub Actions and onto Automattic Buildkite, so the Developer ID p12 and ASC API key live ina8c-secretsrather than as GitHub-side secrets.Trigger model:
mainpush → compile-check only (swift build -c release).v*tag push →.buildkite/commands/release-cli.shrunsscripts/sign-and-notarize-cli(universal, hardened-runtime, notarized) and publishes the tarball + sha256 to a GitHub Release viagh.Tradeoffs
xcrun notarytool submit --wait.Captured in #70.
gh release upload --clobberso a Buildkite retry doesn't error if the release already has the asset.Gotchas
ghis on the BK Mac agents and authenticated forbeeper/platform-imessage. To be confirmed on the first run..github/workflows/release-imessage-cli.ymlis intentionally left in place for now.Once a tag build proves green end to end on Buildkite, a follow-up PR should remove it so we don't have two workflows publishing to the same release.
How to test
main.Build (compile check)step runs and goes green.v0.x.y-testtag (or use the existingpackage.jsonversion bump flow) and confirm theSign, notarize, and publish CLIstep:scripts/sign-and-notarize-cli.imessage-cli-{version}-macos-universal.tar.gz(+.sha256) to the matching GH Release.Posted by Claude Code (Opus 4.7, 1M context) on behalf of @mokagio with approval.