Extract the CI secrets install into a shared script

[mokagio]

Description

Groundwork extracted from #25772 (AINFRA-1538) so the a8c-secrets migration lands as small, independently reviewable pieces.

Two commits, reviewable separately:

1. Install secrets only in jobs that build the app. configure_apply decrypts a single file, Secrets.swift, and its only consumer is the GenerateCredentials.sh Xcode build phase. The release-management and TestFlight-promotion jobs never invoke a compile so the decryption was dead weight in eleven places.
2. Extract the secrets install into a shared script. The six jobs that do build the app now call one install-secrets.sh, so the upcoming swap to a8c-secrets touches one call site instead of six.

Testing instructions

AI-generated

The build jobs on this PR exercise commit 2 directly: prototype and build-for-testing steps must still produce signed builds with real credentials.

Commit 1 touches the release pipelines, which PR CI does not run. To review it, confirm that none of complete_code_freeze, finalize_release, finalize_hotfix, gather_testflight_candidates, promote_build, promote_nightly, code_freeze, new_beta_release, new_hotfix_release, publish_release, or update_appstore_strings reads from ~/.configure. git grep 'configure/wordpress-ios' on trunk returns only GenerateCredentials.sh and its .xcfilelist.

CI so far only proves that the changes haven't broken the Prototype Builds. As for the other pipelines touched, we'll have to run them to have a tangible proof

[Copilot]

Pull request overview

This PR refactors Buildkite pipelines to avoid decrypting CI secrets in jobs that don’t compile the app, and to centralize the remaining secrets install logic into a shared command script to reduce duplication ahead of the upcoming secrets-backend migration.

Changes:

• Removed configure_apply secrets decryption from release-management and promotion jobs that don’t build the app.
• Added a shared .buildkite/commands/install-secrets.sh and updated all build jobs to call it instead of inlining configure_apply.
• Updated job step comments/logging to reflect that non-build jobs now only set up gems.

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
.buildkite/release-pipelines/update-app-store-strings.yml	Removes secrets install from App Store strings update pipeline step.
.buildkite/release-pipelines/publish-release.yml	Removes secrets install from publish release pipeline step.
.buildkite/release-pipelines/new-hotfix.yml	Removes secrets install from new hotfix pipeline step.
.buildkite/release-pipelines/new-beta-release.yml	Removes secrets install from new beta release pipeline step.
.buildkite/release-pipelines/code-freeze.yml	Removes secrets install from code-freeze pipeline step.
.buildkite/commands/release-build-wordpress.sh	Switches build job to shared install-secrets.sh.
.buildkite/commands/release-build-jetpack.sh	Switches build job to shared install-secrets.sh.
.buildkite/commands/prototype-build-wordpress.sh	Switches prototype build job to shared install-secrets.sh.
.buildkite/commands/prototype-build-jetpack.sh	Switches prototype build job to shared install-secrets.sh.
.buildkite/commands/build-for-testing.sh	Switches build-for-testing job to shared install-secrets.sh.
.buildkite/commands/build-and-upload-testflight.sh	Switches TestFlight build/upload job to shared install-secrets.sh.
.buildkite/commands/install-secrets.sh	New shared command that runs bundle exec fastlane run configure_apply.
.buildkite/commands/promote-nightly.sh	Removes secrets install from nightly promotion job (no build).
.buildkite/commands/promote-build-to-public.sh	Removes secrets install from public beta promotion job (no build).
.buildkite/commands/gather-testflight-candidates.sh	Removes secrets install from TestFlight candidate gathering job (no build).
.buildkite/commands/finalize-release.sh	Removes secrets install from finalize release job (no build).
.buildkite/commands/finalize-hotfix.sh	Removes secrets install from finalize hotfix job (no build).
.buildkite/commands/complete-code-freeze.sh	Removes secrets install from complete code freeze job (no build).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	33742
	Version	PR #25884
	Bundle ID	org.wordpress.alpha
	Commit	ba82261
	Installation URL	5fhsap6vfdmi8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	33742
	Version	PR #25884
	Bundle ID	com.jetpack.alpha
	Commit	ba82261
	Installation URL	2bk36poicon38

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[mokagio]

Admittedly, only set -e is used. But, it seems okay to leave the other one set.

[AliSoftware]

Checked in the diff that each pipeline involving build were calling install-secrets.sh and that each pipeline not building anything had their call to configure_apply completely removed. 👍

[AliSoftware]

I'm on two minds about using this vs just hardcoding the path .buildkite/commands/install-secrets.sh here.

I like hardcoding because it avoids an (arguably small and inconsequential) shell-out, and also because I don't have to try to reason about the path while we know that those scripts are always ever going to be invoked by Buildkite itself, in a context where the $PWD is the repo's root.

That being said, in the context of this repo it seems that $(dirname "${BASH_SOURCE[0]}")/ was used everywhere in existing .sh scripts already, so I prefer we prioritize consistency like you did here.

But:

• That makes me wonder if we would want to standardize that across repos (similar to the discussion we had about standardizing shared-pipeline-vars's way to read .xcode-version)
• Even if we don't standardize (yet?) across repos, if we shouldn't use the occasion of this PR to DRY all those $(dirname "${BASH_SOURCE[0]}") done in multiple places in existing scripts into an intermediate SCRIPT_DIR=$(dirname "${BASH_SOURCE[0]}") at the top of each script then reference $SCRIPT_DIR/… instead in later lines of the script. Would not only avoid repetition, but also avoid spawning a shell invocation every time.

[iangmaia]

+1 on either doing SCRIPT_DIR=$(dirname "${BASH_SOURCE[0]}") or just hardcoding 👍
We can at least settle on something and do it from now on (and update it on PRs changing these areas).

[dangermattic]

	1 Warning
⚠️	This PR is assigned to the milestone 27.2. This milestone is due in less than 4 days. Please make sure to get it merged by then or assign it to a milestone with a later deadline.

Generated by 🚫 Danger