Hardening candidates: v2.29.1

[jeiel85]

Candidates surfaced while cutting v2.29.1 — the first release to run the pre-tag export gate from #248. Filed at the tag, not worked on in it. Nothing here blocks the release.

• The GitLab mirror has now missed six eight consecutive releases, and the cause is always the same. The v2.29.1 tag pipeline failed with ci_quota_exceeded on all four jobs (verify_release_docs, verify_android, package_signed_release, publish_gitlab_release). GitLab's newest Release is still v2.27.2 from 2026-07-21 — v2.27.2 was the last one that got through. Hardening candidates: CI artifact retention and release assets #247 records that a missing mirror run is undetectable; this is the third confirmed instance and it is no longer an occasional gap but a standing outage. Either the quota gets addressed, or D064's description of GitLab as a secondary permanent copy should be rewritten to match reality. Affects: the assumption that AAB and mapping have an off-machine permanent home.
  • Re-measured 2026-07-24 against the GitLab API: newest Release is still v2.27.2 (2026-07-21). The gap is now eight releases — v2.28.0, v2.28.1, v2.28.2, v2.28.3, v2.29.0, v2.29.1, v2.30.0, v2.31.0. Two more have shipped since this was filed and neither reached the mirror.
  • Worth separating two things that read as one: refs are fine, Releases are not. mirror-push keeps main and the v* tags in sync, and the daily mirror-check workflow has been green — so the commits and tags for all eight are on GitLab. What is missing is the Release object and its attached AAB/mapping, which only the GitLab CI pipeline creates, and that pipeline is what the quota stops.
  • So the decision is narrower than "fix the mirror": D064 leans on GitLab for the artifacts, and those have had zero coverage since v2.27.2 while the git history has had full coverage the whole time.
• Building a release from an isolated worktree needs a manual secret copy that is documented nowhere. release-signing.properties and .secrets/markleaf-release.p12 are gitignored, so a git worktree-based release checkout cannot run bundleRelease until both are copied in by hand. This release did exactly that and it worked, but docs/RELEASE.md describes the signing setup as though the repo root is always the build location. Worth writing down, since the worktree flow is now the norm for concurrent sessions. Affects: anyone following RELEASE.md from a worktree hitting an unexplained signing failure.
• Store-note length is only checkable after the notes are written. The first draft came in at 545 characters for fr-FR and 517 for es-ES against the 500-char Play limit, and de-DE landed at 484 — all had to be rewritten. Romance-language translations run consistently longer than the English source, so an English note that fits is not evidence the set fits. A rough target for the English draft (~380 chars, which is what this release settled at) would make the first pass land more often. Affects: rework during release prep, and the risk of trimming meaning out under time pressure.
• launch-smoke passed cleanly twice in a row and may no longer need to be non-required. It passed in 8m11s on release: v2.29.1 #250 and again on the v2.29.1 tag run. Hardening candidates: CI artifact retention and release assets #247 asks whether the flake is worth diagnosing; two consecutive clean runs are weak evidence but they are the first data points in a while. Worth watching for a few more releases before deciding, rather than leaving the job permanently excused. Affects: whether the emulator smoke path actually gates anything.
  • More data (measured 2026-07-24, last 6 android-build runs): 4 passed, 1 failed, 1 did not run. The trend this item spotted holds — launch-smoke is no longer the flaky one.
  • The complication is that instrumented-tests arrived in test: make the instrumented suite run, and run it in CI (#235, #239) #272 and failed 3 of those 6 runs, and it is continue-on-error for the same reason. Promoting launch-smoke to required is now a decision about which emulator job earns the gate, not whether the emulator path gets one at all.

[jeiel85]

Audited against the tree at 9969025 (v2.31.0) as part of a sweep over every open hardening tracker. Both measured items were re-measured and the body updated.

The GitLab gap grew from six to eight. GitLab API, 2026-07-24: newest Release is still v2.27.2 (2026-07-21). Missing: v2.28.0, v2.28.1, v2.28.2, v2.28.3, v2.29.0, v2.29.1, v2.30.0, v2.31.0. Two more shipped since this was filed and neither reached the mirror, so "standing outage" was the right reading.

One distinction the original text folded together, worth separating before deciding anything: refs are fine, Releases are not. mirror-push keeps main and the v* tags in sync and the daily mirror-check has been green — the commits and tags for all eight are on GitLab. What is missing is the Release object and its attached AAB/mapping, created only by the GitLab CI pipeline that the quota stops. So the question D064 raises is narrower than "fix the mirror": the git history has had full off-machine coverage the whole time, the artifacts have had none since v2.27.2.

launch-smoke — the trend this item spotted held. 4 passed / 1 failed / 1 not run over the last six android-build runs. The complication is instrumented-tests, added in #272, which failed 3 of those 6 with the same continue-on-error treatment. Promoting launch-smoke to required is now a question of which emulator job earns the gate.

The two unmeasured items stand: docs/RELEASE.md still describes the signing setup as though the repo root is always the build location (no mention of a worktree anywhere in the file), and store-note length is still only checkable after the notes are written (same item in #255 and #262).

[jeiel85]

v2.32.0 (2026-07-25) is the ninth release with no GitLab Release, and the first one to fail loudly — which is the change #275 was after.

The tag job now runs mirror-release-to-gitlab.sh on the GitHub runner, so the CI-minutes quota is no longer what stops it. What stops it now is the credential:

GITLAB_TOKEN was rejected for the Packages API (HTTP 403). The token needs the
'api' scope; 'write_repository' alone cannot publish packages or releases.

So the state after this tag is the same split as before, with one difference:

• Refs: fine. mirror-push carried the tag over — GitLab has v2.32.0 at 5ba597e8.
• Release object and its AAB/mapping: still absent. GitLab's newest Release remains v2.27.2 (2026-07-21), so the gap is now v2.28.0 … v2.32.0, nine releases.
• Detectability: solved. The tag run's release job now exits non-zero and names the cause, instead of the mirror silently doing nothing. That part of this issue can be considered closed.

What is left is a one-line action outside CI: re-issue GITLAB_TOKEN as a project access token with the api scope and replace the repository secret. Until then every tag will fail this step in the same visible way, which is the intended behaviour — the alternative is going back to silence.

The AAB and mapping for v2.32.0 are in D:\Build (markleaf-v2.32.0-vc122.*, verified by verify-release-export.ps1), so nothing is lost while the token is sorted out — but D064's "secondary permanent copy" claim still describes an intent rather than a fact.

[jeiel85]

v2.32.1 (2026-07-27) is the tenth release with no GitLab Release, and the second to fail loudly at the same line:

GITLAB_TOKEN was rejected for the Packages API (HTTP 403). The token needs the
'api' scope; 'write_repository' alone cannot publish packages or releases.

Nothing has changed since the v2.32.0 note above — recorded only to keep the count honest:

• Refs: fine. GitLab has v2.32.1 at ecc79d5, protected, release: null.
• Release object and assets: absent. GET /projects/jeiel85%2Fmarkleaf-android/releases/v2.32.1 → 404. The gap is now v2.28.0 … v2.32.1.
• GitHub: unaffected. The Release published with its APK (2,907,423 bytes, downloaded and verified) before the mirror step ran, so the primary channel never depends on this.

The one-line fix is still the same: re-issue GITLAB_TOKEN with the api scope. Until then every tag run ends red on a step that has already done its GitHub work, which is worth knowing when reading the run list.