ci(example): un-draft Play release, attach release notes, link install URL, platform-selective triggers

[evan-masseau]

Description

Targeted improvements to the example app's Play Store + TestFlight publish workflow now that the listing is mature enough for non-draft submissions, plus tighter trigger granularity so we can publish one platform at a time when needed.

Due Diligence

• I have tested this on a simulator/emulator or a physical device, on iOS and Android (if applicable).
• I have added sufficient unit/integration tests of my changes.
• I have adjusted or added new test cases to team test docs, if applicable.
• I am confident these changes are implemented with feature parity across iOS and Android (if applicable).

Note on iOS feature parity: TestFlight side stays unchanged for the install-link / release-notes parts because xcrun altool (the Apple uploader we use) doesn't emit an install URL — there's no symmetric link to surface in Slack. Release notes for TestFlight ("What to Test") would require a separate API call we don't currently make. Out of scope for this PR. Trigger-selectivity is symmetric across both platforms.

Release/Versioning Considerations

• Patch Contains internal changes or backwards-compatible bug fixes.
• Minor Contains changes to the public API.
• Major Contains breaking changes.
• Contains readme or migration guide changes.
• This is planned work for an upcoming release.

CI-only change, no SDK API surface affected.

Changelog / Code Overview

1. status: draft → status: completed

The listing now has active builds on internal and closed test tracks, so the per-app "Set up your app" requirements are satisfied. Non-draft submissions on the internal track now go live for testers automatically instead of sitting in the Play Console as drafts waiting for manual promotion.

2. Release notes from GitHub release body

r0adkll/upload-google-play@v1.1.3 accepts a whatsNewDirectory containing whatsnew-<locale> files. On release: published events, the workflow writes ${{ github.event.release.body }} (truncated to Play's 500-char per-locale cap, character-aware via bash parameter expansion to avoid splitting multi-byte UTF-8 — caught by Cursor Bugbot, see reply) to ${RUNNER_TEMP}/whatsnew/whatsnew-en-US and passes the dir to the upload action. Other triggers (manual dispatch, push to master, labeled PR) skip the prep step and the build lands without notes — those builds aren't user-facing releases anyway.

3. Install URL in Slack notification

Reading the upload action's source (edits.ts:97–99), the internalSharingDownloadUrl output is emitted for every non-internalsharing track, not just for the internalsharing track as the action's action.yml docstring suggests. The URL format is https://play.google.com/apps/test/<package>/<versionCode> and is only resolvable by users already authorized for the build (no enrollment leak), making it safe to post to a public Slack channel.

The Deploy step now has id: play_upload, the success-notification step passes install_url: ${{ steps.play_upload.outputs.internalSharingDownloadUrl }}, and the notify-slack-publish composite action gained an optional install_url input that conditionally renders an Install: <url> line in the existing details section.

4. Platform-selective triggers

Today the workflow is all-or-nothing — every trigger publishes both Android and iOS. New behavior:

Trigger	Behavior
workflow_dispatch	New platform input dropdown: both (default) / android / ios
pull_request labeled deploy-example-app	Both platforms (existing behavior preserved)
pull_request labeled deploy-example-app:android	Android only
pull_request labeled deploy-example-app:ios	iOS only
release: published	Both platforms (unchanged)
push to master	Both platforms (unchanged)

The cleanup-label job widened to remove whichever variant was applied (startsWith('deploy-example-app') filter, label name pulled from event payload via env var so dynamic).

⚠️ Repo-settings task: The new deploy-example-app:android and deploy-example-app:ios labels need to be created in the repo's Issues → Labels page before they can be applied to PRs. GitHub auto-creates labels for some flows but pull_request: labeled triggers require pre-existing labels.

Test Plan

• YAML parses cleanly (verified via python3 -c 'import yaml; yaml.safe_load(...)').
• Bash parameter expansion verified character-aware locally (hé€ll → 5 chars / 8 bytes, no mid-codepoint cut).
• Trigger the publish workflow via workflow_dispatch against this branch with platform: android, confirm only the Android job runs.
• Same with platform: ios, confirm only the iOS job runs.
• Same with platform: both, confirm both jobs run (regression check on the default path).
• Apply the deploy-example-app:android label to a test PR, confirm only the Android job runs and the label gets removed afterward.
• Confirm the existing deploy-example-app (umbrella) label still triggers both jobs (regression check).
• On the next 2.4.0 GitHub release, confirm the release body shows up as the Play Store internal-track release notes (and that the 500-char truncation behaves on a long body with emojis).
• Confirm the Slack message renders with the new Install: line and the URL opens correctly for an enrolled tester.

Related Issues/Tickets

Follow-up to MAGE-452 (Release RN v2.4.0). Depends on #353 merging first since this branches from ecm/bump-version's tip — once #353 lands on rel/2.4.0, this diff against rel/2.4.0 reduces to just the four changes above.

[cursor]

Cursor Bugbot has reviewed your changes using default mode and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 031775a. Configure here.}

[ndurell]

Solid CI improvement. A couple of non-blocking observations:

whatsNewDirectory on non-release triggers: When the trigger isn't release: published, WHATSNEW_DIR is never set, so ${{ env.WHATSNEW_DIR }} passes an empty string to the upload action. Assuming r0adkll/upload-google-play handles an empty whatsNewDirectory gracefully (no notes attached) — that matches the intended behavior per the PR description, just worth a quick sanity check that the action doesn't error on an empty/unset value.

cleanup-label with platform-selective jobs: When only Android is triggered via deploy-example-app:android, the deploy-ios job is skipped. A skipped job in needs does satisfy always() in GHA, so the label cleanup will correctly run — just a non-obvious behavior worth noting for future maintainers.

Otherwise looks great — the startsWith filter for label cleanup is a clean improvement, the UTF-8 truncation fix is solid, and the platform selectivity is well-structured.