Files
android-client/.github/workflows/build-release.yml
Zoltan Papp 87af5c2cd5 Support ad-hoc snapsot APK from CI (#242)
* Add manual workflow to build a version-code-consistent APK for ad-hoc distribution (#236)

* Add manual workflow to build a version-code-consistent APK for ad-hoc distribution

Adds prepare-publication.yml (workflow_dispatch) that reuses the release
signing key and computes version_code as the combined run count of itself
and build-release.yml, so the two never collide. A shared concurrency
group on both workflows prevents a race on that computation.

* Draw the release version code from the shared run counter

build-release.yml derived its version code from github.run_number, which
counts only its own runs and is blind to prepare-publication.yml. With 25
release runs so far, the first ad-hoc build would take 25+1+40=66 and the
next release would take 26+40=66 as well, then fall behind: 67 after 68 was
already published. The concurrency group cannot fix this, because run_number
is assigned when the run is queued, not when the step executes.

Both workflows now sum the same two counters, so every run of either one
advances the code by exactly one. Reading those counts needs actions: read,
which an explicit permissions block otherwise withholds.

* Name the manual workflow build-snapshot

prepare-publication named a step in a process, while the workflows beside it
name what they produce: build-debug, build-release. What this one produces is
a release-signed build from an arbitrary commit with no tag behind it, which
is what snapshot means.

Not build-rc: release candidates already exist here as published pre-release
tags (v0.6.0-rc.1, v0.3.3-rc.2) and are built by build-release.yml, so the
name would claim a meaning the repository has already given away.

The version code counter is keyed by workflow file name, so the rename is
free only while the workflow has no runs yet.

* Label snapshot builds snapshot- rather than ci-

The version name travels to the management server as the peer's ui_version
and is what the about screen shows, so it is the only thing telling support
which build a peer is running. build-debug.yml already emits ci-<sha> from
the same expression, which left an unsigned PR build and a release-signed
hand-out looking identical in the peer list.

The artifact keeps just the version name; prefixing it again read as
snapshot-artifacts-snapshot-<sha>.

* Resolve the Go version from the submodule's release tags in CI

CI builds used the version only when the submodule sat exactly on a tag and
fell back to ci-<sha> otherwise, which the management server rejects in
NBVersionCheck posture checks: it treats ci- as a development build everywhere
except there. Since the submodule is bumped more often than it is tagged,
release builds effectively always shipped as ci-<sha>.

CI now resolves the version by walking the pinned commit's ancestry back to
the last stable release tag and appending the commit as SemVer build metadata,
e.g. 0.77.0+f06b8c762. The server strips build metadata before every
comparison, so this passes the same gates as a plain 0.77.0 while still naming
the exact commit in the dashboard. Pre-release tags are skipped as a base: a
suffix like -rc.2 lands in SemVer pre-release position, which the server
compares differently from a release.

Local builds now always produce dev-<sha>, which skips every server-side
version gate; a developer who needs a real version passes it as the argument.

The ancestry walk needs full history, but actions/checkout clones submodules
shallow — the tags arrive without the commits between HEAD and the tag, and
the walk would silently come up empty. The composite action therefore
unshallows the submodule before building, guarded because --unshallow on a
complete repository is a hard error.

* Document the three build workflows and their differences

* Fail the build when a run count cannot be fetched

The zero fallback existed for one legitimate case: the runs endpoint returns
404 until a workflow has run or reached the default branch, and treating that
as zero is what lets build-release compute a code before build-snapshot's
first run. But it also swallowed every other failure — a network error or a
revoked token minted a version code far below the published ones, silently
for hand-distributed snapshots.

Keep the 404-means-zero case and abort on everything else, including a
non-numeric response, which bash arithmetic would otherwise fold to zero.

* Pin gobind alongside gomobile instead of running gomobile init (#240)

* Pin gobind alongside gomobile instead of running gomobile init

gomobile bind shells out to gobind, and gobind is the tool that actually
generates the Java bindings and the JNI glue. CI cached and installed only
gomobile and left the build script to call `gomobile init`, which installs
gobind from @latest: the driver was pinned while the generator floated, so
the generated API could change without a commit here.

Take the revision from the go.mod the submodule already carries, so the two
tools cannot drift apart and the cache key follows a submodule bump on its
own, and have the build script check that the pair is present rather than
reaching for gomobile init.

The cache key names both tools now. Entries saved under the old key hold no
gobind, so keeping it would hit the cache, skip the install and leave the
build without a generator.

* Install gomobile and gobind automatically at the go.mod pinned revision

* ci: install the JDK from temurin instead of adopt

setup-java fails to resolve the 'adopt' distribution — AdoptOpenJDK was
renamed to Eclipse Temurin and the old endpoints are going away — so the
build died before installing a JDK. Same JDK, current name.

(cherry picked from commit 8592de3dff)

* Cache the Android NDK and Go modules in the build action
2026-08-17 13:45:55 +02:00

100 lines
3.7 KiB
YAML

name: build release
on:
release:
types: [published]
permissions:
contents: write
# Needed to read the run counts the version code is derived from.
actions: read
concurrency:
group: android-version-code-lock
cancel-in-progress: false
jobs:
build-release:
runs-on: ubuntu-latest
environment: android-release
env:
NETBIRD_UPLOAD_KEY_ALIAS: ${{ secrets.NETBIRD_UPLOAD_KEY_ALIAS }}
NETBIRD_UPLOAD_KEY_PASSWORD: ${{ secrets.NETBIRD_UPLOAD_KEY_PASSWORD }}
NETBIRD_UPLOAD_STORE_PASSWORD: ${{ secrets.NETBIRD_UPLOAD_STORE_PASSWORD }}
outputs:
apk_path: ${{ steps.build.outputs.apk_path }}
bundle_path: ${{ steps.build.outputs.bundle_path }}
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
submodules: recursive
- name: Get version
id: version
run: |
TAG_NAME=${{ github.event.release.tag_name }}
echo "version_name=$TAG_NAME" >> $GITHUB_OUTPUT
- name: Write google-services.json
run: |
echo "${{ secrets.GOOGLE_JSON }}" | base64 -d > app/google-services.json
- name: Write keystore file
run: |
echo "${{ secrets.GPLAY_KEYSTORE }}" | base64 -d > gplay.keystore
echo "NETBIRD_UPLOAD_STORE_FILE=$GITHUB_WORKSPACE/gplay.keystore" >> $GITHUB_ENV
# Must stay identical to the Compute version code step in the sibling
# workflow. build-release.yml and build-snapshot.yml feed the same Play
# Store listing, so they have to draw from one shared counter; a
# github.run_number sees only its own workflow's runs and would hand out a
# code the other already used. The concurrency group above keeps the two
# from computing at once. Renaming either workflow file resets the count
# GitHub keeps for it, which would send version codes backwards.
#
# A 404 means the workflow has never run and is not on the default branch
# yet, which is a true zero. Any other failure aborts the build: falling
# back to zero would mint a version code below already-published ones.
- name: Compute version code
id: version_code
env:
GH_TOKEN: ${{ github.token }}
run: |
count_runs() {
local runs
if runs=$(gh api "repos/${{ github.repository }}/actions/workflows/$1/runs?per_page=1" --jq '.total_count' 2>gh_err.txt); then
if ! [[ "$runs" =~ ^[0-9]+$ ]]; then
echo "::error::unexpected run count for $1: '$runs'" >&2
return 1
fi
echo "$runs"
elif grep -q 'HTTP 404' gh_err.txt; then
echo 0
else
echo "::error::failed to fetch run count for $1: $(cat gh_err.txt)" >&2
return 1
fi
}
release_runs=$(count_runs build-release.yml)
snapshot_runs=$(count_runs build-snapshot.yml)
version_code=$((release_runs + snapshot_runs + 40))
echo "Release runs: $release_runs, snapshot runs: $snapshot_runs -> version_code=$version_code"
echo "version_code=$version_code" >> "$GITHUB_OUTPUT"
- name: Build Android
id: build
uses: ./.github/actions/build-android
with:
version_name: ${{ steps.version.outputs.version_name }}
version_code: ${{ steps.version_code.outputs.version_code }}
build_type: release
- name: Upload files to existing release
uses: softprops/action-gh-release@v1
with:
files: |
${{ steps.build.outputs.apk_path }}
${{ steps.build.outputs.bundle_path }}
tag_name: ${{ github.event.release.tag_name }}