[feature] the Play track is configuration, and the release goes out on the tag - #280
Merged
Conversation
…n the tag Two things stood between `git tag` and a build reaching users. **The service account had no Play access, and the documented way to give it some no longer exists.** `Setup → API access` redirects to the app list; there is no "Release manager" role. Google folded service accounts into ordinary user management and roles into individual permissions, so the path is now Users and permissions → Invite new user, with the service account's email as the user. Granted on 2026-08-20, scoped to Parley alone: view app information, release to testing tracks, release to production. No Cloud-project link is involved anywhere in that flow, which is most of what the old §7 was about. **The track was hard-coded to `internal`.** It is now the `PLAY_TRACK` repository variable, defaulting to `internal`, with a `track` input to override one run. Moving the whole pipeline to production becomes one variable — no commit, no release cut to change a constant. `PLAY_USER_FRACTION` turns a production release into a staged rollout, which is the only undo Play offers once a build is live. The default stays `internal` rather than `production` because production is not reachable yet: the app dashboard reads 6 of 11 setup tasks done, and Play refuses a production release until content rating, data safety, target audience, login details and the app category are filled in. Those are declarations about the app rather than build config, so no amount of CI makes them go away. `versionCode` goes to 2. The first bundle was uploaded by hand on 2026-08-18 as `0.1.0 (1)`, which both clears the first-bundle-cannot-use-the-API problem and burns `versionCode` 1 — `android-v0.1.0` could never have published over the API, whatever else was fixed.
|
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
PLAY_TRACKrepository variable instead of a hard-codedinternal.versionCode→ 2,versionName→ 0.1.1.Why
The documented way to grant Play access no longer exists
Setup → API accessredirects to the app list, and there is no "Release manager" role anywhere in the console. Google folded service accounts into ordinary user management and roles into individual permission checkboxes. Everything §7 said about linking a Cloud project was describing a flow that is gone — no project link is involved at any point now.The current path, and what was granted:
Users and permissions → Invite new user, email
parley-play-publisher@pathors-play.iam.gserviceaccount.com, App permissions tab (not Account permissions, which would apply to every app in the developer account) → Parley only →Deliberately not granted: admin, financial data, order management, test-list management, anything on any other app.
The track was a constant
track: internalwas hard-coded, so "publish to production" meant editing this file and cutting a release to change a string. It is nowPLAY_TRACK(defaultinternal), overridable per-run with thetrackdispatch input.PLAY_USER_FRACTIONturns a production release into a staged rollout — worth having, since it is the only undo Play offers once a build is live.The default stays
internal, and that is not timidity. Production is not reachable yet: the app dashboard reads 已完成 6 項，共 11 項. Outstanding are 登入詳細資料, 內容分級, 目標對象, 資料安全性, and the app category/contact details. Play refuses a production release until they are done, so defaulting to production would fail every release until someone filled in forms that are declarations about the app, not build config. When they are done, flippingPLAY_TRACKtoproductionis the whole change.versionCode 2
The first bundle was uploaded by hand on 2026-08-18 as
0.1.0 (1), sitting on the internal track now. That is good news — it clears the "Play refuses a package's first bundle over the API" problem, so automation takes over from here — but it also burnsversionCode1. Play rejects aversionCodeit has already seen, soandroid-v0.1.0could never have published over the API, whatever else was fixed.How it was verified
tag,track,skip_play_uploadbunx tsc --noEmit,bunx vitest runandroid-v0.1.1right after this merges. Everything before this point was unprovable: no permission, and a burned versionCode.Docs
§7 rewritten: it described a console that no longer exists. Also records what is left before
PLAY_TRACKcan point at production.