ci(release): trigger the publish build via the Buildkite CLI

[dcalhoun]

What?

Step 2 of the release process required opening a Buildkite form and pasting in a commit SHA and version number by hand. The release script now triggers that build itself when the Buildkite CLI (bk) is available, printing the build URL.

Why?

Pasting a SHA into a web form is easy to get wrong, and getting it wrong tags the wrong commit. The script already knows the SHA it just pushed.

How?

bk build create takes the same three inputs the form does:

bk build create -p automattic/gutenbergkit -b trunk \
    -c <sha> -e NEW_VERSION=vX.Y.Z

The CLI is an optional dependency, detected at run time:

• Gated on bk auth status, not command -v bk — an installed-but-unconfigured CLI can't create builds, and finding that out after the version bump is pushed is the worst timing.
• Without it, the script prints the manual steps plus an install hint. No prompting, no state file.
• A failed trigger warns and falls back to the manual steps rather than exiting non-zero — the bump is already pushed, so failing the whole release would misreport it.

The install hint authenticates via bk auth login, which uses OAuth and stores the credential in the OS keyring (bk configure warns that config-file tokens are deprecated). It requests three scopes — read_organizations to complete the login itself, plus read_pipelines and write_builds to resolve the pipeline and create the build. Without --scopes, bk requests every scope the account can reach; on my account that was 35+, including write_pipelines and delete_registries.

Triggering immediately is safe: :rocket: Publish Swift release gates on depends_on (validate, lint, tests, XCFramework), so it waits for its dependencies regardless of when the build starts.

Testing Instructions

Note

Step one requires temporarily commenting out check_branch and check_working_directory.

1. make release VERSION_TYPE=patch DRY_RUN=true — with bk installed and authenticated, prints the bk build create command it would run; without, prints the manual steps and install hint. Nothing is triggered either way.
2. Output opens with DRY RUN MODE and closes with This was a dry run.

Important

The live bk build create call has not been exercised through the release script. Doing so means triggering a real publish build, so we opted to verify on the next real release. The bk invocation itself is known to work against this pipeline, and all four code paths are covered with stubs; a failed trigger degrades to the existing manual process. The one unknown is bk's stdout format on success, which is cosmetic.

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/593")

_{Built from 32b0cef}