ci: fail closed if a pre-release tag would publish to Play production - #245
Merged
ErikBjare merged 2 commits intoAug 30, 2026
Merged
Conversation
The tag→track mapping already sends X.Y.Z to production and everything else to internal (ActivityWatch#182). This makes that contract executable: resolve via scripts/assert-play-track.sh, write the track into the job summary, and refuse to run supply when a pre-release tag would hit production. Also drop the leftover test-job `SUPPLY_TRACK: production` env (it never reached fastlane) so it cannot be copied onto the publish job. Git-Session-Id: 5802
Greptile SummaryThe PR adds a fail-closed Play-track resolver and validates the selected track at the publication boundary.
Confidence Score: 5/5The PR appears safe to merge. The prior missing-track handoff is fixed because the value validated immediately before publication is now passed explicitly to Fastlane, and no blocking failure remains. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
Tag[Release tag] --> Resolve[Resolve Play track]
Resolve --> Assert[Assert tag-track contract]
Assert --> Secrets[Restore Play credentials]
Secrets --> Reassert[Reassert at publish boundary]
Reassert --> Fastlane[Fastlane supply with explicit track]
Fastlane --> Play[Google Play selected track]
Reviews (2): Last reviewed commit: "ci: pass asserted Play track to fastlane..." | Re-trigger Greptile |
supply defaults to production. The historical path was SUPPLY_TRACK via GITHUB_ENV; pass --track explicitly so the asserted value is the one that actually uploads. Git-Session-Id: 5802
Contributor
Author
|
@greptileai review |
Contributor
Author
|
CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click. This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted. |
Judemasic
added a commit
to Judemasic/aw-android
that referenced
this pull request
Sep 2, 2026
Takes ActivityWatch#250 (shared DeviceHostname helper), ActivityWatch#242, ActivityWatch#234, ActivityWatch#244, ActivityWatch#248, ActivityWatch#245. Deliberately NOT taken: ActivityWatch#249's Kotlin half. It declares private external fun setDataDir(path: String) and calls it from SyncInterface's init block, but this fork's android.rs exports no Java_..._SyncInterface_setDataDir - the constructor would throw UnsatisfiedLinkError and SyncScheduler would disable itself, which is Blocker 6 verbatim. This fork already gets the same fix via XDG_DATA_HOME (step 1.0b), which needs no new JNI symbol. The refusal is documented at the call site so the next merge re-checks it. Submodule pointer kept at our fork (c6f7df2); upstream's 2ded7d7 has none of the aw-sync fixes from Phase 1. getDeviceName() now delegates to upstream's deviceHostname(), which is byte-for-byte equivalent to the implementation it replaces - no device directory in the shared folder changes name.
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
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.
Why
#243 reported a GitHub pre-release (
v0.14.0b2) reaching production Play devices. Erik confirmed that was an intentional Play Console promotion from the internal track, not a CI mapping bug (comment).The CI mapping itself is already correct after #182:
X.Y.Z→production, anything else →internal. What was missing is a fail-closed assert at publish time, so a later regression (or copying the leftover test-jobSUPPLY_TRACK: productionenv onto the publish job) cannot silently ship a pre-release tag to production.This does not close #243. Play Console can still promote a track by hand; that is how b2 reached production. The remaining user-facing work on that issue is the bucket-migration path (
aw-android-test-bucket-migration-merge/ #244), not CI.What changed
scripts/assert-play-track.sh— resolve + assert +--self-test(stablev0.14.0→ production;v0.14.0b2/dev/rc→ internal;production+ pre-release tag → hard fail).release-fastlaneuses the script to setSUPPLY_TRACK, writes tag+track to the job summary, asserts after resolve, and asserts again immediately beforefastlane supply run.--self-teston every PR and drops the unused job-levelSUPPLY_TRACK: production(it never reached fastlane).Overlap
#212 also edits
build.yml(signing hardening). Different hunks; rebase this if #212 lands first.Test plan
bash scripts/assert-play-track.sh --self-testresolve v0.14.0b2→internalassert v0.14.0b2 production→ exit 1Assert Play-track resolvergreen on this PR