RunicGateway/Android-app
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 10 Wiki Activity

ci(release): trim setup-android, drop broken Gradle cache, add job timeout #13

Merged
whitlocktech merged 2 commits from ci/release-workflow-speedup into main 2026-07-20 17:50:26 +00:00
Conversation 1 Commits 2 Files Changed 1 +10 -11
wtclaude commented 2026-07-20 17:37:33 +00:00
Member
Copy Link

Why

The Release APK workflow was slow and sometimes appeared to hang mid-build (e.g. run #190 sat with no output during large SDK downloads and R8 minification). None of these are the release blocker itself — they're wall-clock/robustness fixes.

Changes to .gitea/workflows/release.yml

  1. Trim android-actions/setup-android@v3 — pin packages: ''. By default the action pulls the entire Android emulator + the legacy tools package (hundreds of MB, network-bound on the self-hosted runner) that a headless APK build never touches. The very next step (Install Android SDK packages) already installs exactly what we need (platform-tools, platforms;android-35, build-tools;35.0.0).

  2. Drop the Cache Gradle (actions/cache@v4) step — it timed out every run against the Gitea artifact-cache backend (::warning::Failed to restore: getCacheEntry failed: Request timeout), so it added latency with zero caching benefit.

  3. Add timeout-minutes: 30 to the release job — there was no timeout, and with concurrency.cancel-in-progress: false a genuinely wedged run would hang indefinitely and block every later release behind it. Now a hang fails fast.

Notes

  • No change to signing, versioning, the push/tag step, or the release-creation step.
  • Validated the edited YAML parses (yaml.safe_load).

AI disclosure

Authored with assistance from Claude (Claude Code). See commit trailer.

🤖 Generated with Claude Code

## Why The `Release APK` workflow was slow and sometimes *appeared to hang* mid-build (e.g. run #190 sat with no output during large SDK downloads and R8 minification). None of these are the release blocker itself — they're wall-clock/robustness fixes. ## Changes to `.gitea/workflows/release.yml` 1. **Trim `android-actions/setup-android@v3`** — pin `packages: ''`. By default the action pulls the entire Android **emulator** + the legacy `tools` package (hundreds of MB, network-bound on the self-hosted runner) that a headless APK build never touches. The very next step (`Install Android SDK packages`) already installs exactly what we need (`platform-tools`, `platforms;android-35`, `build-tools;35.0.0`). 2. **Drop the `Cache Gradle` (`actions/cache@v4`) step** — it timed out every run against the Gitea artifact-cache backend (`::warning::Failed to restore: getCacheEntry failed: Request timeout`), so it added latency with zero caching benefit. 3. **Add `timeout-minutes: 30` to the `release` job** — there was no timeout, and with `concurrency.cancel-in-progress: false` a genuinely wedged run would hang indefinitely and block every later release behind it. Now a hang fails fast. ## Notes - No change to signing, versioning, the push/tag step, or the release-creation step. - Validated the edited YAML parses (`yaml.safe_load`). ## AI disclosure Authored with assistance from Claude (Claude Code). See commit trailer. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
wtclaude added 1 commit 2026-07-20 17:37:34 +00:00
ci(release): trim setup-android, drop broken Gradle cache, add job timeout
All checks were successful
PR Checks / android-build (pull_request) Successful in 20m43s
Details
b6a0fa1f5d 
The release workflow was slow and sometimes appeared to hang mid-build:

- android-actions/setup-android@v3 pulled the entire Android emulator and the
  legacy `tools` package (hundreds of MB, network-bound on the self-hosted
  runner) that a headless APK build never uses. Pin `packages: ''` so it only
  puts cmdline-tools on PATH; the next step installs exactly what we need.
- The `actions/cache@v4` Gradle step timed out every run against the Gitea
  artifact-cache backend (`getCacheEntry failed: Request timeout`), adding
  latency with no benefit. Dropped it.
- The job had no timeout, and with `concurrency.cancel-in-progress: false` a
  genuinely wedged run would hang forever and block every later release behind
  it. Added `timeout-minutes: 30` so a hang fails fast.

Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech approved these changes 2026-07-20 17:37:58 +00:00
whitlocktech scheduled this pull request to auto merge when all checks succeed 2026-07-20 17:38:05 +00:00
wtclaude added 1 commit 2026-07-20 17:39:36 +00:00
ci(release): fix workflow file mangled by prior base64 double-encode
All checks were successful
PR Checks / android-build (pull_request) Successful in 10m19s
Details
2d84a930e5 
Restore proper YAML content (the previous commit on this branch accidentally
stored the base64 string as the literal file body).
whitlocktech merged commit 0c395b2527 into main 2026-07-20 17:50:26 +00:00
whitlocktech deleted branch ci/release-workflow-speedup 2026-07-20 17:50:27 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
whitlocktech
Labels
Clear labels
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
wontfix
This won't be fixed
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ksfixitman whitlocktech wtclaude
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RunicGateway/Android-app#13
No description provided.
Delete Branch "ci/release-workflow-speedup"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?