[Tooling] Upload CDN builds as drafts, publish in publish_release

[iangmaia]

Related issues

• This PR depends on the PRs:
  • Add update_apps_cdn_build_metadata action wordpress-mobile/release-toolkit#701 (adds update_apps_cdn_build_metadata action)
  • Add list_apps_cdn_builds action wordpress-mobile/release-toolkit#702 (adds list_apps_cdn_builds action)
• Fixes AINFRA-2102

How AI was used in this PR

Claude Code was used to implement the Fastfile changes based on a detailed plan I designed. I reviewed all generated code.

Proposed Changes

• Upload all non-beta CDN builds as drafts with external visibility (previously published immediately), so they're not publicly accessible during the testing period
• Beta builds continue to be published immediately (no post_status: 'draft')
• Add make_cdn_builds_public helper that queries the CDN API via list_apps_cdn_builds to find draft builds for the release version, then publishes each via update_apps_cdn_build_metadata
• Call make_cdn_builds_public in publish_release before publishing the GitHub release
• Update finalize_release prompt to mention the new draft behavior

Why drafts instead of internal visibility?

Integration testing against the real CDN API revealed that posts with visibility: internal are completely hidden from all listing queries (by CDN plugin design), making it impossible to find and flip them later. The draft/publish approach works reliably and is idempotent — re-running when no drafts exist is a safe no-op.

Testing Instructions

• Full end-to-end testing will happen during the next release cycle
• The draft→publish flow was manually verified against the real CDN API

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the release automation to upload Apps CDN artifacts as Internal first (for an internal testing window), and then flips them to External as part of publish_release before the GitHub release is published.

Changes:

• Change Apps CDN uploads to use Internal visibility by default.
• Add make_cdn_builds_public helper to find internal builds for a release version and update them to External visibility.
• Update release lane prompts and call make_cdn_builds_public during publish_release.

---

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

[iangmaia]

Converted to draft until the release-toolkit PRs aren't merged and we can use a new version with both actions.

[AliSoftware]

Integration testing against the real CDN API revealed that posts with visibility: internal are completely hidden from all listing queries (by CDN plugin design), making it impossible to find and flip them later. The draft/publish approach works reliably and is idempotent — re-running when no drafts exist is a safe no-op.

What is the consequence of uploading a build to AppsCDN as "Draft", in terms of testability?
I'm guessing that just like a WP post, an app uploaded as "Draft" would not be visible when you load the WP site that lists the builds (just like draft posts aren't visible on a blog), so how would a Release Manager or the team be able to download and test the build in practice?

Maybe it'd be better to adjust the CDN plugin design to allow list_apps_cdn_builds to return internal builds somehow… though I guess it'd only allow listing internal builds if the call is done from a proxied IP, while CI machines (where those lanes run) are not proxied, so I guess that's the core of the problem… In that case I could think of 2 possible solutions:

• Either use Draft status instead of visibility, like you did, but then ensuring it'd be possible (and easy) for the Release Manager to download the build for testing
• Or store the post_id of the build that is uploaded as draft — but the question is where… maybe as some <!-- post_id:… --> hidden metadata in the GitHub Release draft description? Or as an annotation to the Buildkite build? — so you wouldn't have to use list_apps_cdn_builds to retrieve it later.

[AliSoftware]

I'm not sure the condition is right here?

This means that the first beta post code freeze as well as the intermediate betas that occur in the middle of the release will be uploaded as draft (and then never published). While those should probably be internal instead.

That also means that the final build we do at the end of the release process, the one that drops the beta suffix because it's supposed to be the final version, will not match the /beta/i RegEx, and thus will be uploaded as non-draft. While it's exactly not what we want.

Also, based on the code at the start of this lane, there also exists "Nightly Builds"—for which release_tag is nil, which means means this will publish those as non-draft as well.

---

I think instead we should:

• For build_type of both Nightly and Beta, use visibility: :internal but post_status: 'publish', so that they are published but only internally
• For build_type == 'Production builds, especially the final build done at the end of the release scenario, use visibility: :external but post_status: 'draft'… until we get to the next stage in the Release Scenario to publish it once it has been smoke-tested.

[AliSoftware]

This is not consistent with what it currently does, which is not about making it public and changing it from internal to external, but about changing it from draft to published…

Of course this might change back depending of if using the Draft state was indeed the right move (i.e. if it still allows this build to be easily downloadable and testable by the team and RM for smoke-testing) or if we're gonna switch back to using internal vs external.

[AliSoftware]

Is there a risk—especially in the rare case that issues was found in a final release build and the team decides to make a new commit on the release/ branch then re-upload a new final build—that there would be more than one build with version v#{version} in the CDN for each platform, and that we'd then end up publishing all of them (the bad one as well as the subsequent one with the fix) instead of only the last one?

Tbh I'm not sure this is a case the current setup fully support yet anyway.

• e.g. what happens to the version bump logic if you finalize_release once, which removes the -betaN suffix from the version, then find an issue and redo another finalize_release, would the logic that removes the -betaN be a no-op on the version already being X.Y.Z? Will it crash?
• What about the AppsCDN side of things, is the CDN plugin ok with uploading a build with the same metadata (version, platform…) twice? Does it replace the old one with the new one in that case, or keep both entries (which is where your list_apps_cdn_builds call would return duplicates)

Maybe it's only a concern for a future iteration though. But I figured I'd still raise the question, including in case this informs our thoughts about using visibility: :internal and not using list_apps_cdn_builds but storing the post_id values at initial upload time somewhere instead.