fix(ci): executable gradlew, and tag.yml token/permissions

[stozo04]

Two fixes from the first dry run.

./gradlew: Permission denied

gradlew is mode 100644 in the index. Git on Windows doesn't track the executable bit, so it has never mattered locally — but a Linux runner checks the file out non-executable and can't run it. chmod +x gradlew now runs immediately before the build.

Done in the workflow rather than by changing the index mode, so CI is fixed without touching the tree and stays fixed either way. If you'd rather correct it at the source too, git update-index --chmod=+x gradlew locally and commit — the chmod here is harmless once that lands.

tag.yml had the same empty-token bug

It still passed token: ${{ secrets.RELEASE_TOKEN }} with no fallback, so run 2 would have died at checkout exactly like run 1 did. Now falls back to GITHUB_TOKEN.

Also raised its permissions to contents: write — cutting a tag and creating a release is a write, and it would have failed at the last step under read-only. Worth noting: tags aren't covered by the branch ruleset, so run 2 needs no PAT or App token at all. Only run 1's merge does.

What the dry run already proved

Checkout, JDK 17, Android SDK and the keystore check all passed — compileSdk 37 installed fine, and the five signing secrets are correct. R8 and jarsigner are still unproven; this run should reach them.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Miqsf1M14nY5TKiZHzyjNY

---

Note

Low Risk
CI workflow-only changes (build chmod, token fallbacks, permissions); no app runtime or signing logic changes.

Overview
Fixes release CI failures from the first dry run: Linux runners can’t execute ./gradlew because the wrapper is checked out as non-executable when the index mode is 100644 (common when the repo is edited on Windows). The release build step now runs chmod +x gradlew immediately before bundleRelease, with set -euo pipefail on that step.

Run 2 (tag.yml) no longer hard-requires RELEASE_TOKEN: checkout and GH_TOKEN fall back to github.token, and job permissions are raised to contents: write so tagging and creating the GitHub release can succeed. Comments clarify that tags aren’t covered by the branch ruleset, so run 2 doesn’t need a PAT/App token—only run 1’s merge does.

The missing-RELEASE_TOKEN error in release.yml is updated to describe bypassing the ruleset (fine-grained PAT or GitHub App token), not only “contents + pull-requests write.”

^{Reviewed by Cursor Bugbot for commit 6d472bc. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.}

^{Reviewed by Cursor Bugbot for commit 6d472bc. Configure here.}

[cursor]

Missing actions permission for artifact download

High Severity

The job now falls back to github.token with only contents: write, so actions is none. gh run download of another run’s artifacts needs actions: read. When RELEASE_TOKEN is unset, fetch fails with 403 and the tag is never cut.

Additional Locations (1)

• .github/workflows/tag.yml#L63-L68

 

^{Reviewed by Cursor Bugbot for commit 6d472bc. Configure here.}