recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ffb34dfcfaca2cfd0ae1a5535a60995068cd275c
cc-ci/machine-docs/BACKLOG-gtea.md
autonomic-bot ffb34dfcfa
Some checks failed
continuous-integration/drone/push Build is failing
Details
chore(gtea): M1 PASS recorded; M2 builds #675 #676 in flight 
M1: ADVERSARY PASS @20:32Z (a106036).
M2:
- Bridge POLL_REPOS now includes recipe-maintainers/gitea (86deceb)
- Build #675: Drone direct trigger RECIPE=gitea REF=main PR=0 (real CI on main)
- Build #676: !testme on PR #1 (lfs-plain-gitea head, LFS capstone)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-15 20:35:47 +00:00

2.6 KiB
Raw Blame History

BACKLOG — phase gtea (gitea full-test enrollment)

Build backlog

(Builder-owned — read-only to Adversary)

  • 0. Prerequisites verified (timezone, recipe, backup labels)
  • 1. Write all gitea test files (recipe_meta.py + ops.py + lifecycle overlays + custom + PARITY.md)
  • 2. Run harness locally against cc-ci (install + upgrade + backup + restore + custom) on gitea main Run 846690: level=5/5 (all PASS). Fixes: _csrf→user_name selector; cred_url git push; auto_init repo; token scopes for gitea 1.22+; NixOS git-lfs deploy.
  • 3. Confirm drone CI stays green (dep path unaffected by recipe_meta.py changes) Unit tests pass (10/10 gitea dep + 43/43 meta). Drone dep path byte-for-byte unchanged.
  • 4. Verify LFS test correctly skips on main (compose.lfs.yml absent) SKIPPED with expected message in run 846690. PASS.
  • 5. CLAIM M1 — ADVERSARY PASS @2026-06-15T20:32Z (commit a106036)
  • 6. Run full harness via real CI / !testme on gitea recipe IN FLIGHT: Drone build #675 (RECIPE=gitea REF=main PR=0) — triggered 20:34Z
  • 7. Run harness on lfs-plain-gitea head → LFS test must go green IN FLIGHT: Drone build #676 (PR=1 REF=357926f2) — !testme posted 20:34Z
  • 8. Post !testme on PR #1 so result lands in PR DONE (posted 20:34Z, build #676, PENDING)
  • 9. CLAIM M2 (await Adversary PASS)
  • 10. Write ## DONE (all Adversary PASSes)

Adversary findings

(Adversary-owned — only the Adversary writes this section)

[non-blocking] Stale screenshot in manual runs @2026-06-15T20:32Z

/var/lib/cc-ci-runs/manual/screenshot.png mtime = June 13, not from today's M1 run.

Root cause: screenshot.capture() (screenshot.py:149) checks if not os.path.exists(out_path) after the SCREENSHOT hook runs. For run_id="manual", out_path reuses the same directory (/var/lib/cc-ci-runs/manual/screenshot.png), so if a prior manual run left a file there, the guard prevents overwriting it. The SCREENSHOT hook (recipe_meta.py) navigates to the login page but doesn't call page.screenshot() itself — that's the harness's job, blocked by the guard.

Impact: results.json shows "screenshot": "screenshot.png" (file exists, non-empty) but the image is from a prior session. Cosmetic only — does not affect verdict (R7). M2 runs with DRONE_BUILD_NUMBER → unique dir → no issue.

Recommendation: screenshot.capture() should always overwrite (remove if not exists guard), or the Builder could add page.screenshot(path=out_path) at the end of the SCREENSHOT hook. No action required for M1/M2 gates. Pre-existing harness limitation, not Builder error.