Date: 2026-08-13
Branch: test/real-provider-e2e (PR #124 open against main)
PR #124 ("feat(e2e): real-provider E2E with multi-run isolation (Phases 0-2)") is now fully
green. It started this session already containing the Phase 2 multi-run-isolation work
(namespace scheme, 3-layer cleanup hierarchy, per-source/provider concurrency) from a prior
session, but the first push (c8382cb) had three real bugs, all found and fixed here:
ci.yml'sprovider-e2ejob setE2E_WORKDIRusing${{ runner.temp }}inside a job-levelenv:block — therunnercontext isn't allowed there, so GitHub Actions rejected the whole workflow file at parse time (0 jobs ever created for that push, noCI/CDcheck run at all). Fixed by computingE2E_WORKDIRin an unconditional first step instead, via$GITHUB_ENV.- SonarCloud's Security Rating gate failed (D, required ≥A):
sha1sumin the branch-hashing helper (switched tosha256sum), unpinnedactions/checkout/setup-node/paths-filterin the new jobs/workflows (pinned to full SHAs), missing--ignore-scriptson the new job'snpm ci, and justified# NOSONARsuppressions onhttp://calls that only ever talk to a per-run Docker-bridge-only Gitea sandbox. A same-day follow-up fixed a NOSONAR-placement bug (marker landed on the wrong line of two multi-linecurlstatements). provider-e2e's concurrency group keyed PR runs by PR number and branch-only runs by branch name — different groups for the same branch when it has an open PR, so a push fired both apushand apull_requestrun concurrently against the same shared GitLab sandbox and starved each other's real API calls. Reproduced twice (real400: Deadline Exceededand atestConnectiontimeout on thepull_request-triggered run, while thepush-triggered run for the identical commit passed cleanly both times). Fixed by keying the group by branch name alone (github.head_ref || github.ref_name) regardless of trigger event, and updating the two cleanup workflows' groups to match. User was asked and explicitly chose "fix the dedup now" over deferring. Verified by re-pushing: the duplicate run this time correctly got cancelled by the concurrency group instead of racing, and the survivor passed 100% clean.
All automated checks pass and were captured as evidence in progress.md: actionlint 0 errors,
npx eslint . 0 errors, npm run build clean, npx vitest run 527 passed, a live local Gitea
E2E run (14/14, run twice against real Docker), and PR #124's CI/CD run fully green (real
GitHub/GitLab/Gitea E2E, SonarCloud Security Rating A, Node 22/24 tests, build/release/package).
PR #124 is ready — #124. Nothing is
currently blocking it (note: main's branch protection ruleset is disabled, so CI status isn't
enforced, but it's genuinely green regardless). Next step is for the user to review and merge it,
or ask for further changes.
After merge, pick up:
Priority 1: item 0a in progress.md — re-enable the gitea leg in CI (currently gated off in
ci.yml's "Determine whether this provider leg should run" step after earlier runner-topology
failures that were already fixed in code but never re-verified live). Harness code passes locally
every time; this is a "flip the gate back on and watch one more real CI run" task, not new
development.
Priority 2: Pick next issue from GitHub Project #6 backlog (see feature_list.json — re-sync
against GitHub Issues first, it's the source of truth).
actionlint (v1.7.12 binary) -> 0 errors on all 4 workflow files
npx eslint . -> 0 errors
npm run build -> clean (incl. Obsidian 1.11.0 compat typecheck)
npx vitest run -> 36 files, 527 tests passed
npm run test:e2e -- --provider gitea -> 14/14 passed (real local Docker sandbox, run twice)
PR #124 CI/CD (surviving run) -> fully green: E2E/github, E2E/gitlab, E2E/gitea (gated-skip),
E2E gate, CI Lint, Test Node 22/24, Build and Release,
Package Artifact, SonarCloud Code Analysis (Security Rating A)
- test/real-provider-e2e — PR #124 open against
main, green, ready for review/merge. - main — unaffected, no changes.