[fix] a release that cannot reach Play fails instead of reporting success - #276
Merged
Conversation
…cess `android-release.yml` skipped its Play upload whenever `PLAY_SERVICE_ACCOUNT_JSON` was unset. That was defensible exactly as long as the secret could not exist: the Play Developer API is gated behind a verified developer account, and account 6541030546953107772 was pending verification when the workflow was written. Verification cleared on 2026-08-17, so the condition is gone and what is left is a workflow that goes green without publishing anything. That is the worst shape a release job can have — the tag is used up, the GitHub release exists, the `.aab` is signed and attached, and the only thing missing is the one thing the job is for. Nobody finds out until somebody asks where the build went, and `android-v0.1.0` is exactly that: green, and not on Play. A missing secret is now a hard error naming the fix. The one case that genuinely cannot use the API — the first bundle for a package, which Play refuses until a release exists in the console — becomes an explicit `skip_play_upload` input on a manual run, so skipping is something an operator asks for rather than something a missing secret decides quietly. That path writes to the step summary and raises a warning annotation, because the run is green and the summary is the only place that can say the build is not on Play. Also adds `android/scripts/create-play-service-account.sh`, which does the whole Cloud half — project, `androidpublisher`, service account with no project-level IAM roles, JSON key, `gh secret set`, patchbay, and deleting the local copy — idempotently, and prints the two steps that have no API behind them. Linking a Cloud project to a Play account is what *enables* the Play Developer API, so it cannot go through the API it enables; that and the Release manager grant stay Play Console web UI. RELEASING.md's §7 and the secrets table said "blocked on verification", which has not been true since 2026-08-17.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
android-release.ymlnow fails when it cannot reach Play, instead of skipping the upload and reporting success. Addsandroid/scripts/create-play-service-account.shfor the half of the setup that has an API.Why
The skip was conditioned on
PLAY_SERVICE_ACCOUNT_JSONbeing unset, and that was defensible for exactly as long as the secret could not exist — the Play Developer API is gated behind a verified developer account, and6541030546953107772was pending verification when the workflow was written.Verification cleared on 2026-08-17. What is left is a release job that goes green without publishing:
Nobody finds out until someone asks where the build went.
android-v0.1.0is that run — green, and not on Play.skip_play_upload=trueon a manual run::notice::in the log::warning::annotationSkipping is now something an operator asks for, not something a missing secret decides quietly.
inputs.skip_play_uploadis null on a tag push, so!inputs.skip_play_uploadis true there — tags always have to publish, and onlyworkflow_dispatchcan opt out.The script
gcloud auth login(as the Play account owner) then:Creates the
pathors-playproject, enablesandroidpublisher, createsparley-play-publisherwith no project-level IAM roles (everything it may do is granted in the Play Console instead), mints a JSON key,gh secret sets it, files it in patchbay, and deletes the local copy. Idempotent — re-running reuses the project and account and only mints a fresh key.Two steps have no API and the script prints them rather than pretending otherwise: linking the Cloud project to the Play account is what enables the Play Developer API, so it cannot go through the API it enables, and the Release manager grant lives on the same Console page.
How it was verified
bunx tsc --noEmitpassesbunx vitest runpassesworkflow_dispatchinputs aretag,skip_play_uploadbash -non the script, and ran it — it stops at the first gate (the gcloud token for … is stale — run: gcloud auth login), which is the current state of this machine's loginsThe upload path itself is still unproven, because the service account does not exist yet — that is the point of the error this PR adds.
Docs
§7 and the secrets table said "blocked on verification", which has not been true since 2026-08-17.