mirror of
https://github.com/netbirdio/android-client.git
synced 2026-09-23 09:30:52 -07:00
fix/debug-bundle-anonymize-level
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Zoltan Papp
|
1d40d8f095 |
Align the Android client with the iOS and desktop clients (#179)
Reworks the Android UI, and brings over features the desktop client already had. |
||
|
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
|