DO NOT MERGE: verify Sentry upload on CI

[mokagio]

Do not merge. Stacked on #5708 purely to answer one question, then to be closed and deleted.

Description

#5708 moves the Sentry upload auth token out of the configure-provisioned secret.properties and into the SENTRY_AUTH_TOKEN environment variable, and inlines the org and per-module project slugs. Nothing in normal CI exercises any of that: every build path passes -PskipSentryProguardMappingUpload=true, so the upload tasks are never registered. Without this, the first real test of the new wiring is the next code freeze.

This adds a temporary step that does the upload for real, so we find out now.

• Runs the upload tasks, not a release assemble. uploadSentryProguardMappingsRelease pulls in minifyReleaseWithR8, which produces the mapping, but leaves packaging and signing out of the graph.
• All three modules. app, automotive and wear each declare their own Sentry project slug — pocket-casts-android, pocket-casts-automotive, pocket-casts-wear — newly inlined in Use public Sentry org/project, env-injected token #5708. The token has to authenticate against all three, so a typo in one would otherwise surface only at release.
• Side effect to be aware of. A successful run uploads real ProGuard mappings to the three production Sentry projects. Mappings are addressed by debug ID, so a spare one is dead weight rather than corruption.

What the result means

• Step passes — the token reaches the android queue agents, providers.environmentVariable picks it up, and the a8c org plus all three project slugs authenticate. Use public Sentry org/project, env-injected token #5708 is safe to merge.
• Step fails on the guard (SENTRY_AUTH_TOKEN is not set (or is blank).) — the token is not exported on the queue and needs adding before Use public Sentry org/project, env-injected token #5708 merges. The log prints a bare present/absent line before the build starts, to tell this apart from a Gradle-side problem.
• Step fails inside sentry-cli — the token is there, but an org/project slug or the token's scope is wrong.

Testing Instructions

1. Wait for the :sentry: Verify Sentry Upload step.
2. Confirm it passes, and that new mappings appear under a8c/pocket-casts-android, a8c/pocket-casts-automotive and a8c/pocket-casts-wear in Sentry.

Other failures on this branch are not expected. Nothing here should be "fixed" — close the PR once it has answered the question.

Checklist

• If this is a user-facing change, I have added an entry in CHANGELOG.md — n/a, CI-only and throwaway
• Ensure the linter passes
• I have considered whether it makes sense to add tests for my changes — n/a, this PR is the test

[claude]

Claude finished @mokagio's task in 4m 9s —— View job

---

Review: throwaway Sentry upload verification

• Read the diff against ainfra-2790-remove-sentryproperties-in-favor-of-public-values-and-env
• Compare the new script with the existing .buildkite/commands/* conventions
• Check the pipeline step (indentation, agents, plugins, env)
• Verify the Gradle task names and Sentry wiring from the base branch
• Post review (3 inline comments)

The approach is sound and the script follows the house style closely — restore-cache.sh → install_gems → configure_apply matches assemble-release-apk.sh and prototype-build.sh line for line, and going after the upload tasks instead of assembleRelease is the right call for keeping signing and packaging out of the graph. I checked the module list too: app, automotive and wear are the only three that apply libs.plugins.sentry, so "all three modules" is genuinely complete — tv appears in aggregatedLintRelease but never gets the Sentry plugin, so there's no fourth slug to worry about.

Three things, one of which I'd act on before letting the build decide anything.

1. --continue is missing, and the PR's own rationale needs it. (verify-sentry-upload.sh:31) Gradle stops at the first failing task, so if the app slug is wrong you learn nothing about automotive or wear — precisely the "a typo in one would otherwise surface only at release" case the three-module run exists to catch. One extra flag turns a possible three-round-trip debug into one run. Fix this →

2. The task name is unverified, and a wrong one is indistinguishable from broken wiring. grep across the tree and git log -S find uploadSentryProguardMappingsRelease nowhere but this script — no CI path has ever named a Sentry task, because they all skip the upload. If that isn't the name sentry-plugin = "6.18.0" registers, the step fails with Task ... not found in project ':app' and the question goes unanswered. Same error text you'd get if CI weren't truthy, since build.gradle.kts:484-486 gates includeProguardMapping (and therefore task registration) on it. Confirming once locally with CI=true ./gradlew :app:tasks --all | grep -i sentry, plus echoing CI next to the existing token line, makes all three failure modes tellable apart from the log alone. Fix this →

3. The source-context upload isn't covered, which narrows what a green run proves. build.gradle.kts:487 sets includeSourceContext from the same flag, and the real release path — build_bundle calling gradle(task: ":#{app}:bundle", build_type: 'Release') at fastlane/Fastfile:596 — passes no skipSentryProguardMappingUpload. So at code freeze the source-bundle upload also hits the a8c org and those three slugs for the first time. Requesting only the mapping task leaves that half untested. Pulling it in would upload PR-branch source code to the three production projects, a meaningfully heavier side effect than the spare mapping the description already accounts for, so leaving it out may well be right — but then "step passes ⇒ #5708 is safe to merge" is narrower than it reads, and worth qualifying in the description.

On the other axes: no security concern, the token is tested with -n and never echoed, and ${SENTRY_AUTH_TOKEN:-} is correctly written for the set -u from #!/bin/bash -eu. The step inherits the top-level queue: "android" with no override, which is the queue the description wants to prove the token reaches. Dropping the should-skip-job.sh guard the sibling build scripts open with is fine and arguably deliberate — .buildkite/** isn't in COMMON_PATTERNS, so it could never skip on this branch. Performance isn't worth optimising for a throwaway, though three sequential R8 runs on one agent is a long job; splitting into three parallel steps like the "Assemble release APKs" group would be faster and isolate failures per module, if --continue alone doesn't feel like enough.

Nothing here blocks the PR from doing its job. Worth folding in #1 before reading the result, since without it a red build may answer only a third of the question.
• branch mokagio/sentry-upload-ci-validation

[dangermattic]

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger

[claude]

Without --continue, the first failing task aborts the build and the other two modules never run — which defeats the stated reason for running all three ("a typo in one would otherwise surface only at release"). If the app slug were wrong, this step tells you nothing about automotive or wear, and you'd need a second round trip through CI to find out.

--continue still fails the step, but it reports every module's outcome in one run:

Suggested change

	./gradlew \
	:app:uploadSentryProguardMappingsRelease \
	:automotive:uploadSentryProguardMappingsRelease \
	:wear:uploadSentryProguardMappingsRelease
	./gradlew --continue \
	:app:uploadSentryProguardMappingsRelease \
	:automotive:uploadSentryProguardMappingsRelease \
	:wear:uploadSentryProguardMappingsRelease

Two related notes on this invocation:

The task name is unverified anywhere in the repo. grep over the tree and git log -S both turn up nothing but this script — no CI path has ever named a Sentry task, since they all skip the upload. If uploadSentryProguardMappingsRelease is not what the plugin (sentry-plugin = "6.18.0") registers, the step dies with Task 'uploadSentryProguardMappingsRelease' not found in project ':app', which reads like broken wiring rather than a typo in this script, and the PR's question goes unanswered. Worth confirming once with CI=true ./gradlew :app:tasks --all | grep -i sentry before trusting a red build here.

The source-context upload is not exercised. build.gradle.kts:487 sets includeSourceContext = shouldUploadDebugFiles from the same flag, and the real release path (build_bundle → gradle(task: ":#{app}:bundle", build_type: 'Release') in fastlane/Fastfile:596) passes no skipSentryProguardMappingUpload, so at code freeze the source-bundle upload runs against the same org and slugs for the first time too. Requesting only the mapping task leaves that half untested. Adding it would mean uploading PR-branch source code to the three production projects, which is a heavier side effect than the spare mapping the description accounts for — so it may well be the right call to leave out. If so, worth saying explicitly in the description, since "step passes ⇒ #5708 is safe to merge" is then narrower than it reads.

[claude]

The token check itself is right: ${SENTRY_AUTH_TOKEN:-} keeps set -u happy and the value is never echoed, only its presence.

It's one variable short of covering the failure modes, though. build.gradle.kts:484-486 gates includeProguardMapping on System.getenv()["CI"].toBoolean(), and the plugin only registers the upload tasks when that is true — so if CI is unset or not literally true, the run fails with Task ... not found, indistinguishable from a wrong task name and nothing to do with the token. Buildkite exports CI=true, so this is about keeping the log self-diagnosing rather than a likely break, and it costs one line:

Suggested change

	echo "--- :key: Checking SENTRY_AUTH_TOKEN"
	if [ -n "${SENTRY_AUTH_TOKEN:-}" ]; then
	echo "SENTRY_AUTH_TOKEN is present"
	else
	echo "SENTRY_AUTH_TOKEN is absent"
	fi
	echo "--- :key: Checking Sentry upload preconditions"
	if [ -n "${SENTRY_AUTH_TOKEN:-}" ]; then
	echo "SENTRY_AUTH_TOKEN is present"
	else
	echo "SENTRY_AUTH_TOKEN is absent"
	fi
	# The upload tasks only exist when `CI` is truthy, because that is what gates
	# `includeProguardMapping` in `applyCommonSentryConfiguration`. An unexpected value here surfaces as
	# "task not found", which looks nothing like a token problem.
	echo "CI=${CI:-<unset>}"

[claude]

Cosmetic, but it costs nothing to avoid: the step lands immediately above the ########## Optional Prototype Builds ########## banner (indented under the group that follows it), so the banner now reads as documentation for this step. Appending the step at the end of the file instead would both keep that banner attached to its group and make the eventual deletion a single trailing hunk.

The rest of the step is consistent with its neighbours — plugins: [ $CI_TOOLKIT ], and no agents: override so it inherits the top-level queue: "android", which is the queue the description wants to test the token on.

Omitting the should-skip-job.sh --job-type build guard that assemble-release-apk.sh and prototype-build.sh open with is also the right call here: .buildkite/** isn't in COMMON_PATTERNS, so it would never skip on this branch anyway, and you want this step to run unconditionally.