Add update_apps_cdn_build_metadata action

[iangmaia]

Fixes AINFRA-2102

Summary

• Adds a new update_apps_cdn_build_metadata Fastlane action that updates metadata of existing builds on the Apps CDN without re-uploading files
• Uses the WP REST API v2 (POST /wp/v2/sites/{site_id}/a8c_cdn_build/{post_id}) with JSON body
• Accepts an array of post_ids to update multiple builds in one call — the visibility term ID lookup is performed only once and reused across all posts
• Supports updating visibility (:internal / :external) via taxonomy term ID lookup, and post_status (publish / draft)
• This enables a two-phase release flow: upload builds as Internal during finalize, then flip to External at publish time

Context

The companion Studio PR uses this action in its publish_release lane to flip CDN build visibility from Internal to External.

The existing upload_build_to_apps_cdn action cannot be used to change visibility because visibility is part of the dedup matching criteria in the CDN plugin — re-uploading with a different visibility creates a new build rather than updating the existing one.

Note: The v1.1 API (/rest/v1.1/sites/{site_id}/posts/{post_id}) returns 500 for a8c_cdn_build custom post types, which is why this action uses the WP v2 endpoint instead.

Test plan

• Unit tests added and passing (bundle exec rspec spec/update_apps_cdn_build_metadata_spec.rb — 16 examples, 0 failures)
• bundle exec rubocop — no offenses on changed files
• Manual test: verified against the real CDN API that both visibility updates and post_status changes work correctly via the v2 endpoint

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a new Fastlane action to update metadata on an existing Apps CDN build post via the WordPress.com REST API, enabling a two-phase release flow (upload internal → later flip to external without re-upload).

Changes:

• Introduces update_apps_cdn_build_metadata Fastlane action that POSTs updates to an Apps CDN build post (visibility/status).
• Adds RSpec coverage for successful updates, validation, and error handling.
• Documents the new action in the Trunk changelog.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
spec/update_apps_cdn_build_metadata_spec.rb	Adds unit tests for the new action’s request shaping, validation, and error cases.
lib/fastlane/plugin/wpmreleasetoolkit/actions/common/update_apps_cdn_build_metadata.rb	Implements the new Fastlane action that updates build metadata via WPCOM REST API.
CHANGELOG.md	Adds a Trunk “New Features” entry for the new action.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dangermattic]

	1 Warning
⚠️	This PR is larger than 500 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.

Generated by 🚫 Danger

[AliSoftware]

Probably more of a question for Hannah but it feels surprising to me that the API would technically allow an array if values for this metadata instead of a single one 🤔

Like, what would happen at the API level if we called the API with {"visibility":[1345, 1367]} body (where, say, 1345 is internal and 1367 is external, for example) 😅

[iangmaia]

Just double checked using the API. It indeed accepts multiple term IDs and assigns both:

POST /wp/v2/sites/{site_id}/a8c_cdn_build/737
{"visibility": [1316, 21293]}

→ 200 OK
{"id": 737, "visibility": [21293, 1316], ...}

So a post would end up being both "internal" and "external" at the same time 😅 it just treats visibility as a taxonomy that supports multiple terms.

[AliSoftware]

Interesting! I wonder why we didn't have to pass an array but just a string in the API call that creates the build in upload_build_to_apps_cdn then 🤔 🤷

Also, this doesn't match the table in the FieldGuide documentation (interal ref: PCYsg-15tP-p2#How-to-upload-a-build-to-a-CDN-blog), so I guess one of the 2 should probably be updated.
I'd vote for only updating the AppsCDN plugin for accepting only one visibility (both in the API call and on the visibility metadata stored for a post taxonomy), but I'm not sure if that's technically feasible/easy (vs if this is an inherent technical limitation of how taxonomies work in WordPress? cc @hannahtinkler).

Anyway, I think ultimately it's not really critical (given the way we use the API and this visibility taxonomy we always set only one value in practice in all our call sites); as long as we're sure that calling update_build_to_apps_cdn with a one-item array [term_id] on a post that already had a different value set for visibility indeed replaces the visibility of that post with a single visibility value of term_id—as opposed to adding it to the existing ones.

[AliSoftware]

2 small suggestions for also DRY-ing the ConfigItems or at least their verify_block: procs into the Helper, as well as integrating the URI.parse(url) calls into the {rest_v1_1,wp_v2}_url helpers directly.
But LGTM apart from that, so approving to unblock.

[AliSoftware]