ci: align Buildkite step labels, emoji, and keys

[dcalhoun]

Note

Due to the CI label renames, the repository's required checks configuration must be changed in order to merge this PR. To receive passing CI results, pending PRs will need to rebase atop trunk once this merges.

What?

Rename CI tasks for consistency.

Why?

Overtime, CI tasks labels became increasingly inconsistent, making it more difficult to quickly assess CI results.

How?

• Update labels to resemble the <verb>[-<what>][-<how>] grammar from refactor: align Makefile target names with a documented grammar #705
• Group CI tasks by platform via a single platform emoji

Testing Instructions

N/A, no user-facing changes.

Accessibility Testing Instructions

N/A, no user-facing changes.

Screenshots or screencast

Before	After

---

AI-generated details

Step emoji mixed platforms, languages, and tools (:swift:, :xcode:, :rocket:, :eslint:, :npm:, :react:), so one area of the codebase appeared under several icons and GitHub's alphabetical check list scattered related steps. Keys had also drifted from the make targets they run.

Rule

Documented in a comment above steps::

• One emoji per step, naming the platform it builds, tests, or ships: :javascript: (standing in for web — there is no clean web glyph), :ios:, or :android:.
• Verb-first, title-case labels that stand on their own without the emoji.
• Key = the make target the step runs or mirrors, where there is one.
• Explicit check names: each step reports its GitHub check under a notify: github_commit_status context, which is the label minus its emoji (and minus the release version). Label tweaks no longer rename required checks, and a diff that changes a context signals a ruleset update (review thread).

Labels

Before	After
:react: Build React App	:javascript: Build Web Bundle
:eslint: Lint React App	:javascript: Lint Web
:javascript: Test JavaScript	:javascript: Test Web Unit
:npm: Check @wordpress package versions	:javascript: Check @wordpress Package Versions
:performing_arts: Test Web E2E	:javascript: Test Web E2E
:swift: SwiftLint	:ios: Lint iOS
:swift: iOS Simulator Tests	:ios: Test iOS Library Simulator
:swift: Library Tests	:ios: Test iOS Library Host
:xcode: Build XCFramework	:ios: Build XCFramework
:s3: Publish XCFramework to S3	:ios: Publish XCFramework to S3
:swift: :package: Publish PR XCFramework	:ios: Publish PR XCFramework
:white_check_mark: Validate Swift release	:ios: Validate Swift Release
:rocket: Publish Swift release	:ios: Publish Swift Release
:ios: Test iOS E2E	:ios: Test iOS App E2E
:android: Test Android Library	:android: Test Android Library Unit
:android: Test Android E2E	:android: Test Android App E2E
:android: Test Android Library Instrumented	:android: Test Android Library E2E
:wastebasket: Clean up … branches for closed PRs	:ios: Clean Up … Branches for Closed PRs

Labels follow the platform-named make targets from #705. :ios: also covers the Swift host tests, which run on macOS: the emoji names the platform the code is for, matching how :android: already covers the Android library's JVM unit tests.

References to the renamed steps are updated in AGENTS.md, docs/releases.md, bin/release.sh, and an Android test comment. The --- :emoji: log section headers inside commands and scripts are log formatting, not step labels, and are left alone.

Keys

Before	After
build-react	build
lint-js	lint-web
test-js	test-web-unit
lint-swift	lint-ios
swift-test-swift-package	test-ios-library-simulator
swift-test-library	test-ios-library-host
build-xcframework	build-ios-resources-xcframework
test-ios-e2e	test-ios-app-e2e
(none)	lint-android, test-android-library-unit, test-android-app-e2e, test-android-library-e2e

The web bundle step runs make build after its own prerequisites, so it takes that key. lint-ios runs the SwiftLint Docker image rather than make lint-ios, but mirrors it with the same pinned version and config. The release scripts' --step artifact downloads follow the XCFramework key.

⚠️ Merge prerequisite: ruleset update

All nine checks the Protect default branch ruleset requires move from label-derived names to the explicit contexts:

Required context (buildkite/gutenbergkit/…)	Becomes
react-build-react-app	Build Web Bundle
eslint-lint-react-app	Lint Web
javascript-test-javascript	Test Web Unit
performing-arts-test-web-e2e	Test Web E2E
swift-ios-simulator-tests	Test iOS Library Simulator
swift-library-tests	Test iOS Library Host
ios-test-ios-e2e	Test iOS App E2E
android-test-android-library	Test Android Library Unit
android-publish-android-library	Publish Android Library

The new contexts are confirmed against this PR's CI run (build #3180), posted by the same Buildkite app as the old ones. Until the Buildkite CI configuration PR disables the label-derived statuses, every step reports under both names.

Merge in this order:

1. Swap the nine contexts in the ruleset.
2. Merge this PR. Other open PRs pick up the new contexts once they merge trunk.
3. Merge and deploy the Buildkite CI configuration change. Deploying it before step 2 would leave trunk-based PRs without any required statuses.

🤖 Generated with Claude Code

[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/714")

_{Built from 424a6a5}

[mokagio]

Due to the CI label renames, the repository's required checks configuration must be changed in order to merge this PR. To receive passing CI results, pending PRs will need to rebase atop trunk once this merges.

To avoid this issue cropping up in the future, we can 1) required every step and group to use notify.github_commit_status; 2) update the pipeline setting to force reporting the custom status instead of deriving from the label name (that's outside of this repo's scope)

Example for 1:

Suggested change

	- label: ':ios: Validate Swift Release ${NEW_VERSION:-(no version)}'
	key: validate-release
	if: build.env("NEW_VERSION") != null && build.branch == "trunk" && build.pull_request.id == null
	command: |
	install_gems
	bundle exec fastlane validate "version:$NEW_VERSION"
	plugins: *plugins
	- label: ':ios: Validate Swift Release ${NEW_VERSION:-(no version)}'
	key: validate-release
	if: build.env("NEW_VERSION") != null && build.branch == "trunk" && build.pull_request.id == null
	command: |
	install_gems
	bundle exec fastlane validate "version:$NEW_VERSION"
	plugins: *plugins
	notify:
	- github_commit_status:
	context: Validate Swift Release

[mokagio]

2. update the pipeline setting to force reporting the custom status instead of deriving from the label name (that's outside of this repo's scope)

If this suggestion resonates, I opened a PR in our private Buildkite configuration repository.

If it doesn't and you want to merge sooner without coordination, that's fine, too. My team will eventually get to adopt the approach in all repos and we'll update the GitHub checks settings one more time then. No dramas.

[oguzkocer]

@mokagio Wouldn't that move the same problem to a different layer? If we do this, the next time a rename happens we'll have to make a decision on whether to rename the custom labels or not. If we rename, we are back to square one with more to maintain, if we don't, now the action and the label are potentially out of sync or doesn't match the current naming scheme.

Especially in a small repo that won't impact many branches, nor would it require expensive rebases, the fix sounds like it creates more problems than it solves. But, that's just my take on it. Happy to leave the decision to you regardless.

[dcalhoun]

@mokagio interested in your thoughts on @oguzkocer perspective when you have time, no rush. I plan to leave this PR for the time being as it is not urgent.

[AliSoftware]

Gio has gone AFK for ≈ a month, but here's my take:

Sure it moves the problem to a different layer, but one key is that the notify: { github_commit_status: "…" } approach allows you to have a clean GitHub check name that is free of formatting or emojis etc, while keeping the label of the step in Buildkite's own UI nicer and fancier.

1️⃣ Indeed when only relying on the label: of the step, Buildkite will derive the GitHub check name by replacing emojis with :code:, add buildkite/gutenbergkit/ prefixes, etc, which (at leasts IMHO) makes them less readable in GitHub PRs' UI. So personally I think the benefit of using notify: { github_commit_status: "…" } is also about better readability of the GitHub check names on GitHub PRs' UI.
For example, using an explicit notify: { github_commit_status: "Test iOS App E2E" } on the label: ':ios: Test iOS App E2E' step will allow you to have it shown as a nice "Test iOS App E2E" line in the GitHub checks at the bottom of the PR rather than the more ugly buildkite/gutenbergkit/ios-test-ios-app-e2e.

2️⃣ To Gio's point though, the other benefit of decoupling github_commit_status from label is that if you decide to make a minimal change to the label: of a step (e.g. changing label: ':s3: Publish XCFramework to S3' to label: ':ios: Publish XCFramework to S3', or changing label: ':swift: :package: Publish PR XCFramework' to label: ':ios: Publish PR XCFramework'), at least this won't change the GitHub Check name/identifier under you, and thus if you used a commit_status that still makes senses before/after (e.g. github_commit_status: 'Publish XCFramework to S3' / github_commit_status: 'Publish PR XCFramework' without the emoji), this won't require you to update the GitHub repo's settings to update the "Required Checks" list on the branch protection settings just for that. The label: and the GitHub check name can be kept independent instead of every little change of a label implicitly changing the GitHub check name under you.

Of course, if you do change the semantics of what a step does and that you end up changing its label: not just for a typo fix or for a change of emoji, but for a change in meaning, you'll probably still want to also update the notify: { github_commit_status: "…" } part of the step alongside your change of its label: to make the GitHub check name reflect that change of semantics too (e.g. for label: ':android: Test Android Library Instrumented' -> label: ':android: Test Android Library E2E' you'd probably also want to update github_commit_status: 'Test Android Library Instrumented' -> github_commit_status: 'Test Android Library E2E'). And thus would still have to update the branch protection settings accordingly.
But at least:

1. You only need to do that when you change the semantics of the step—and that also changing the GitHub check name would also make sense—not just when you change an emoji or small typo fix
2. You can provide a more readable GitHub check name than the one derived by Buildkite from the label (no more buildkite/gutenbergkit/ prefix, no transformation of :ios: emoji code from the label: into an ios- prefix in the check name…)
3. It's immediately clear from the diff when your change will require updating the branch protection settings. If you change just the label: but not the github_commit_status, no need to update the branch protection settings; only if your PR makes changes to the github_commit_status will it be an explicit signal/reminder to update the settings. While today with the GitHub commit status name derived from the label: it might not be as obvious to PR authors or reviewers that changing the label: will have this unfortunate consequence, making them more likely to forget to update the settings.

[dcalhoun]

Thank you for the helpful explanation. 🙇🏻‍♂️ I added the suggested notify.github_commit_status to each task. I believe the next steps are:

1. Update the repository's required checks to the new tasks
2. Merge this PR
3. Merge and deploy the Buildkite CI PR Gio referenced earlier

I believe No. 3 must occur last, and the only impact between merges will be that duplicate tasks will show up on PR reports.

@AliSoftware would you be willing to help with No. 3 after this PR merges? I can merge early next week.

[AliSoftware]

@AliSoftware would you be willing to help with No. 3 after this PR merges? I can merge early next week.

Sure thing. It'd be easy enough since Gio already prepared the PR, which is here. So it'd just be a matter of (rebasing it + undraft it +) hit the button to deploy it once you did 1 & 2.

[dcalhoun]

@AliSoftware thank you! This PR was merged and the project's required checks are updated. We can proceed with the Buildkite CI PR.

hit the button to deploy

Is this the PR merge button or a separate deploy action? I originally requested your assistance because I presumed it was the latter, a separate deploy step for which I lack permissions. If it is simply merging the PR, I'm happy to manage that, just let me know. 🙇🏻‍♂️

[AliSoftware]

It's a different button, I can take care of it 🙂

[AliSoftware]

Done, the buildkite/gutenbergkit/… entries on GitHub PR checks should not appear on new PRs, only keeping the explicit ones you provided now.