2 Commits

Include renames

Author	SHA1	Message	Date
3 people	96401f4c10	feat(forge): Phases 2+2.1+3 — Gitea + GitLab providers, per-call routing, local-merge fallback (#575) ... * feat(forge): Phase 2 — Gitea provider, per-call routing, host registry Gitea support lands behind the Phase-1 seam: - GiteaProvider (services/forge/gitea.py): Gitea v1 transport addressed by instance host (api base from the project's git_url). Where Gitea's wire contract diverges from GitHub's, the provider adapts responses back into the shapes GitService already classifies (ShapedResponse): `token` auth scheme, duplicate-PR 409→422 with the "already exists" text GitService keys on, commit statuses reshaped into check_runs / workflow_runs envelopes, APPROVE→APPROVED review mapping, Do-keyed POST merge, merge-method repo keys, label-color '#' prefix, client-side head/base PR filtering. Deliberate postures per the spec: zero-workflows fail-open (statuses-free repo → no_ci_configured) and merge_branch as a shaped 501 (env-sync cascade lands on missing_ref; the shared local-git fallback is Phase-2.1). - ForgeRouter (services/forge/router.py): GitService._forge now routes per call from RepoRef.host — every existing call site unchanged in shape. RepoRef gains an optional host; _parse_git_url returns the host-stamped ref and it is threaded through GitService/release executor instead of being rebuilt from strings (helpers re-signatured to take RepoRef). - Host registry (services/forge/registry.py): in-memory host→provider map, self-healing — ProjectService.get/get_by_slug re-register on every read; provider_for resolves gitea projects by git_url host. - Registration validation now accepts git_provider="gitea"; GitLab remains recognized-but-rejected. Panel: the read-only Forge badge becomes a real picker (Auto-detect / GitHub-GHE / Gitea / GitLab disabled). Plain git (clone/fetch/push) needs no changes — the Basic-auth extraheader works on Gitea unchanged. Gates: mypy 392 files, xenon A, full unit suite 6356 green, integration suite 2257 green. * feat(forge): live-Gitea contract suite + scheme support + slash-safe refs Hardening from running the provider against a real dockerized Gitea 1.22.6 (the spec's Phase-2 contract suite, now committed as the env-gated tests/e2e_smoke/test_gitea_live.py — self-seeding: creates its own repo, pushes real commits, and drives PR open → duplicate reshape → list/filter → diff → review → labels → commit-status CI reshapes → squash merge → branch delete → release, plus a live verification of the x-access-token Basic-auth git-CLI claim). Two real findings fixed: - Branch refs weren't URL-encoded — every RoboCo branch carries slashes (feature/backend/...), and Gitea's router 404s on the extra path segments. list_ci_runs + delete_branch_ref now quote the ref (regression-pinned in the unit suite). - The API base hardcoded https; a LAN instance serving plain http is a real deployment shape. GiteaProvider gains a scheme (recorded per host by the registry from the project's git_url). ShapedResponse moves to forge/shaping.py (shared by the upcoming GitLab transport, which needs its text override for diff reassembly). * feat(forge): Phase 3 GitLab provider + Phase 2.1 local-merge fallback GitLabProvider (services/forge/gitlab.py): GitLab v4 transport addressed by host+scheme, subgroup-safe (the MR project path packs into RepoRef.owner, URL-encoded per call). Adapters translate MR semantics into the GitHub shapes GitService classifies: iid→number, source/target_branch→head/base with a merged bool, per-file diffs reassembled into unified-diff text (ShapedResponse text override, 3-page cap), approve-vs-note review routing (GitLab has no request-changes verb), pipelines/statuses reshaped into workflow_runs/check_runs, merge-method repo-key mapping, duplicate-MR 409→422. Reviewer mirroring is skipped (needs numeric ids RoboCo doesn't store); provisioning stays Phase 4. gitlab.com now auto-detects at registration like github.com; self-hosted GitLab sets the provider explicitly (panel picker enabled). Phase 2.1: neither Gitea nor GitLab has GitHub's server-side merges API — their merge_branch returns a shaped 501 and GitService.sync_env_branch now runs the shared local-git fallback (_local_merge_branch: throwaway clone → ancestor check → merge → push; a conflict aborts with the remote untouched; same status vocabulary as the merges-API path). Also aligns the whole tree with the full gate's tests/-scoped mypy (provider-test responder typing, e2e_smoke's stale owner/repo shapes). Gates: mypy 1229 files clean, xenon A, unit suite 6393 green, forge suites 85 green, panel typecheck/lint clean. --------- Co-authored-by: Renn F <rennf93@users.noreply.github.com>	2026-07-19 08:12:34 +02:00
3 people	2c403c77a2	Fix/run hardening prep (#263) ... * fix(git): don't delete a branch that still has open dependent PRs Root cause of the run-zombifying "integration branch gone from origin" wedge. _delete_remote_branch_best_effort deleted a merged PR's head branch unconditionally, so: - merging a cell->root PR deleted the cell branch while a sibling leaf PR was still targeting it as base, and - the CEO's root->master merge deleted the feature/main_pm/{root} integration branch. The dependent PRs lost their base, every later git op against the vanished branch failed, and the task zombified (a51c3d31 only made the post-merge sync non-fatal; this removes the cause). The remote-branch delete chokepoint (the single path all merge/close/cancel deletions funnel through) now first checks _branch_has_open_dependents: any OPEN PR targeting the branch as its base marks it an active integration target and preserves it. Fails safe (any error => keep the branch; cleanup is best-effort, stranding is not). True leaf branches with no open dependents are still cleaned up. Adds 6 unit tests for the guard + the probe. * fix(git): recover a drifted shared clone on resume instead of BRANCH_MISMATCH A dev/documenter/QA clone is shared across that agent's tasks. On a respawn/resume it can sit on a sibling task's branch, or a re-provisioned clone can lack the task branch as a local ref (commits only on origin). The fresh-claim path git-resets the clone clean, but resume deliberately short-circuits before it (_dev_reentry), so the agent's next commit hit _assert_on_task_branch's BRANCH_MISMATCH, failed, and the task wedged in a blocked respawn loop (the documenter that could never land its doc commit). _assert_on_task_branch now recovers instead of only rejecting: fetch + checkout the task branch (recreating a missing local ref from origin via `git branch <b> origin/<b>`), and raise only when the switch genuinely can't happen (uncommitted changes block it). Never discards work — checkout, not reset — so a resumed agent's unpushed commits are preserved. Updates the RAG troubleshooting + developer docs to describe the auto-recovery. Adds 5 unit tests. * fix(runtime): re-adopt running agent containers on restart (no double-spawn) An orchestrator restart loses the in-memory _instances registry while the agent containers keep running. The reaper already had a Docker-liveness fallback (_assignee_container_running), but the spawn gate (_is_agent_active) did not, so right after a restart it saw a live agent as inactive and could launch a second container onto work the forgotten-but-running one was already doing. start() now calls _readopt_running_agents() after _reconcile_orphan_claims_on_startup and before the dispatcher/reaper loops launch: it probes each known agent slug's container (AGENT_IMAGES, reusing _inspect_container_state — the same docker inspect the reaper uses) and registers a minimal AgentInstance(state=ACTIVE) for any that is running and not already tracked. Inert when nothing runs (cold start unchanged); best-effort (a probe error leaves that slot for the reaper's own fallback). This is the gateway-health spec's Task 4 / the orchestrator-state spec's Phase 3 (_instances reconcile). Adds 4 unit tests. * fix(git): treat an already-merged PR as idempotent success on merge A merge PUT against an already-merged PR returns the same 405 as a genuine "not mergeable" conflict, so _merge_with_retry raised MergeConflictError and the completion path tried to rebase / close-superseded / escalate a PR that had already landed (a prior cycle, a sibling, or the CEO merged it) — the cell_pm_complete block<->unblock respawn loop. _merge_with_retry now disambiguates before raising: a new _pr_is_merged probe (GET the PR, check merged==true) returns success on an already-merged PR so completion proceeds idempotently; a genuinely-unmerged 405 still raises the conflict. Best-effort probe (False on any error → falls through to the existing conflict handling). Adds 4 unit tests. --------- Co-authored-by: Renn F <rennf93@users.noreply.github.com>	2026-06-25 18:35:52 +02:00