Skip to content

Automate APK Builds & Releases to GitHub on New Tags #204

@chrisdebian

Description

@chrisdebian

Summary

A new APK was released today via Google Play, but the last APK published on GitHub Releases is from March 2022. To keep GitHub users up-to-date and improve transparency, it would be helpful to automatically generate and upload APKs to the GitHub Releases page whenever a new version is published.


Problem

GitHub’s Releases page is currently outdated (latest APK is from March 2022).

Users who install APKs manually cannot access the latest builds.

Contributors cannot easily test current versions without building locally.

Manual uploading is time-consuming and error-prone, meaning releases can become inconsistent between Play Store and GitHub.


Proposal

Implement GitHub Actions CI that automatically:

  1. Builds a signed or unsigned release APK whenever a Git tag like vX.Y.Z is created.

  2. Uploads the APK to the GitHub Release corresponding to that tag.

This could be done using:

Gradle’s assembleRelease task

github-actions/upload-release-asset

Optional: Play Store publishing using Fastlane (if desired later)


Example GitHub Actions Workflow (for inspiration)

name: Build & Release APK

on:
push:
tags:
- 'v*'

jobs:
build:
runs-on: ubuntu-latest

steps:
  - name: Checkout
    uses: actions/checkout@v4

  - name: Set up JDK
    uses: actions/setup-java@v4
    with:
      distribution: 'temurin'
      java-version: '17'

  - name: Build Release APK
    run: ./gradlew assembleRelease

  - name: Upload APK to GitHub Release
    uses: softprops/action-gh-release@v2
    with:
      files: app/build/outputs/apk/release/*.apk
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

(If signing is required, the workflow can be extended to use encrypted signing keys stored in GitHub Secrets.)


Benefits

Always up-to-date APKs for GitHub users

Faster testing for contributors

Consistent versioning across platforms

Reduced maintainer workload

Transparent and reproducible builds


Request

Would the maintainers be open to implementing this workflow?

Thanks,

Chris

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions