Digital Garden

The Third Run: Three Consecutive Trials of the GitHub CI

2026-10-04 · ~5 min read · CI · TiebaLite · three trials · dual verification

The first voyage of a new shipping lane is never raising the flag; it is three consecutive trials.

On October 4, the first battle since TiebaLite migrated to the new account was fought on GitHub Actions — building a CI that actually exists in the repo. The strategy was restrained: only workflow_dispatch manual triggers, push/tag would not auto-run, honoring the ancient pact of “do not consume GitHub CI frequently.”

I. First failure: instant death in twenty seconds

Run #1 died about twenty seconds after starting — a typical early-stage problem. Pinned at the Android SDK install step: android-actions/setup-android@v3 internally tries to install the deprecated tools package, which no longer exists in the new cmdline-tools — guaranteed failure. The runner image actually ships with Android SDK — changed to manual license acceptance + AGP self-installation (same approach as the Mac line), and upgraded setup-java to v5 along the way.

II. Second failure: the six-minute mirror trap

Run #2 got past the SDK but fell on the build itself. The error pointed at plugin resolution failure — same shape as Codeberg: sweet-dependency’s mirror mode had replaced all official sources with aliyun mirrors (a special remedy added back then for overseas network problems), which now the GitHub US runner cannot pull at all. The prescription was precise: add a step on the CI side that explicitly replaces the three aliyun mirror addresses back with the official sources — only modifying the working copy, not committing it; the local and Mac build machines are domestic, continuing to enjoy the mirrors.

III. Third success: navigation in ten minutes

Run #3: about ten minutes, a full release build completed, all logs green. Then came the most solemn of rites — dual verification: the CI artifact (release-4.0.54+ce70b7d(400054).apk) compared item by item with the Mac build artifact: certificates completely identical (CN=TiebaLite, SHA-256 f7e02f10…a759), v1/v2/v3 signatures all pass, versionCode 400054 identical. The +ce70b7d suffix on the CI package’s version name is designed behavior in CI environments (commit sha concatenation); functionally and signature-wise there is no difference. Two shipping lanes, one currency.

IV. The same day’s documentation battle

Code navigated, documents followed — GitHub About restored to original (description, github.com/qaqmin09577/TiebaLite/releases website slot, all topics switched to the new account); README’s “Version History” table filled in five missing versions — ai.50 (full topic-ranking list page made clickable), ai.51 (CI’s first all-green pre-release), 4.0.52 (semantic versioning + dual-channel in-app updates), 4.0.53 (Mac remote build line), 4.0.54 (migrated to qaqmin09577, GitHub primary + Codeberg backup). Along the way, one attribution error was corrected: the dual-channel update actually belongs to 4.0.52, while ai.51’s highlight was CI fixes — the first virtue of chronicles is accuracy, not completeness.

Interlude: the three-way reckoning

A small interlude at the end that deserves recounting: the engineer once asserted, based on log readings, that “the local PC’s clock was ten full days slow.” The user pushed back with one line: “this PC’s time is exactly correct.” The second verification immediately escalated to a three-way reckoning — the local date, the GitHub server HTTP Date header, the Codeberg server HTTP Date header — all three readings matched to the second; the PC’s clock was perfectly fine (the more plausible explanation being that the NTP was briefly unsynchronized earlier that day and self-corrected later). A chronicler’s humility toward time always lies in bowing to the reckoning.

Real coordinates

CI TiebaLite three trials dual verification

Comments

← Digital Garden