CI signing: use the repo's actual keystore secret names#27
Conversation
The signing workflows referenced UPLOAD_KEYSTORE_BASE64 / UPLOAD_KEYSTORE_PASSWORD / UPLOAD_KEY_ALIAS / UPLOAD_KEY_PASSWORD — none of which exist as repo secrets, so the keystore decoded empty and the passwords came back blank, making gradle fall back to UNSIGNED builds. Point the workflows at the real secrets: KEYSTORE_RAW -> base64 keystore, decoded to upload.jks KEYSTORE_SECRET -> store password (QUICLOC_KEYSTORE_PASSWORD env) KEY_ALIAS -> key alias KEY_SECRET -> key password (QUICLOC_KEY_PASSWORD env) PLAY_SERVICE_ACCOUNT_JSON (unchanged) The internal QUICLOC_* env-var names gradle reads are unchanged. Updated the release-play header comment, build-apk header comment, and PLAY_PUBLISHING.md secret tables to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UkMUU9nhTAZBkKwpuyBdtw
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @HereLiesAz, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the naming convention of the GitHub secrets used for signing release builds, renaming the UPLOAD_* secrets to KEYSTORE_RAW, KEYSTORE_SECRET, KEY_ALIAS, and KEY_SECRET. These changes are applied to the GitHub Actions workflows in repo_backup.txt and documented in docs/PLAY_PUBLISHING.md. As there are no review comments, I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
Sorry @HereLiesAz, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
2 participants
Why
The signing workflows referenced secrets that don't exist in this repo —
UPLOAD_KEYSTORE_BASE64,UPLOAD_KEYSTORE_PASSWORD,UPLOAD_KEY_ALIAS,UPLOAD_KEY_PASSWORD. The effect: the keystore decoded to an empty file and the passwords came back blank, so gradle'shasReleaseSigningwas false and it silently fell back to unsigned builds. That's why the "signed" builds weren't signed.What
Point both signing workflows (
build-apk.ymldispatch path,release-play.yml) at the repo's actual secret names:.jks, decoded toupload.jks)KEYSTORE_RAWKEYSTORE_SECRETKEY_ALIASKEY_SECRETPLAY_SERVICE_ACCOUNT_JSON(unchanged)The internal
QUICLOC_*env-var names gradle actually reads (signingProp(...)inapp/build.gradle.kts) are unchanged — the workflows just feed them from the correct secrets now. Header comments anddocs/PLAY_PUBLISHING.mdsecret tables updated to match. NoUPLOAD_*references remain; YAML validates.Assumption to confirm
KEYSTORE_RAWis decoded withbase64 --decode(i.e. I'm assuming it's the base64-encoded.jks, the standard way to put a binary keystore in a GitHub secret). If it's stored in some other form, the keystore load will fail at build time with a clear error — tell me the encoding and I'll adjust.Verification
This can only be fully confirmed by a dispatch run (the signed paths need the secrets, which CI on a PR doesn't expose): run Build and Publish QuicLoc APK (or Release to Play) and confirm the output is signed (
apksigner verify/jarsigner -verify). The PR's normal CI only builds the unsigned debug path.🤖 Generated with Claude Code
Generated by Claude Code