FM-4 GitLab end-to-end smoke (real repo, dispatch loop, board render) #655

Open
opened 2026-05-01 18:33:08 +00:00 by claude-desktop · 2 comments
Collaborator

User story

As a platform engineer, I want a real GitLab repo watched by claude-hooks with the full dispatch loop (issue → implement → review → merge) closing successfully, so that the multi-forge claim from forge-mcp-multi-forge.md is validated end-to-end on a non-Forgejo backend.

Acceptance criteria

Webhook config

  • webhook-config.json::repos adds an entry pointing at a GitLab repo (operator-controlled — forge.jacquin.app/charles/... mirror, or a gitlab.com project of your choice). The entry's forge field is "gitlab".
  • GitLab webhook configured on that project to send Issue Hook, Merge Request Hook, Note Hook, Pipeline Hook events to https://claude.jacquin.app/webhooks/gitlab (or equivalent route — coordinate with apps/server/src/http/webhook.ts).
  • Same HMAC pattern as Forgejo for signature verification.

Dispatch loop

  • Create an issue on the GitLab repo, assign dev. The webhook fires, the dispatcher constructs an implement task, the agent's mcp__forge__* calls hit the GitLab adapter via forge-mcp.
  • Agent creates an MR. Reviewer is requested. Reviewer agent picks up, reads MR diff (getPullRequestDiff adapter call), submits APPROVE or REQUEST_CHANGES via submitReview (GitLab approve / unapprove + discussion mapping).
  • Boss merges the MR via mergePullRequest (GitLab squash).
  • Issue auto-closes (GitLab Closes #N keyword in MR body).

Dashboard

  • The board renders the GitLab card alongside Forgejo cards under the same Triage / per-agent columns. PR pill renders correctly with GitLab CI state. Card click opens the side panel with MR diff link.

Tests

  • Integration test against recorded GitLab REST fixtures (no live GitLab in CI) walks the entire dispatch loop.
  • Manual: one real issue on a real GitLab repo, watched and processed end-to-end. Capture command + screenshots in the closing PR description.

Out of scope

  • GitHub end-to-end smoke (file separately if needed).
  • GitLab CI integration beyond reading pipeline status.
  • A second GitLab repo (one is enough to validate).

References

  • specs/forge-mcp-multi-forge.md §Story FM-4
  • specs/multi-forge.md §MF-7 — multi-forge dispatch tests, this extends
  • apps/server/src/infrastructure/forge/gitlab-adapter.ts
  • Depends on FM-1, FM-2, FM-3.
## User story As a platform engineer, I want a real GitLab repo watched by `claude-hooks` with the full dispatch loop (issue → implement → review → merge) closing successfully, so that the multi-forge claim from `forge-mcp-multi-forge.md` is validated end-to-end on a non-Forgejo backend. ## Acceptance criteria ### Webhook config - [ ] `webhook-config.json::repos` adds an entry pointing at a GitLab repo (operator-controlled — `forge.jacquin.app/charles/...` mirror, or a `gitlab.com` project of your choice). The entry's `forge` field is `"gitlab"`. - [ ] GitLab webhook configured on that project to send `Issue Hook`, `Merge Request Hook`, `Note Hook`, `Pipeline Hook` events to `https://claude.jacquin.app/webhooks/gitlab` (or equivalent route — coordinate with `apps/server/src/http/webhook.ts`). - [ ] Same HMAC pattern as Forgejo for signature verification. ### Dispatch loop - [ ] Create an issue on the GitLab repo, assign `dev`. The webhook fires, the dispatcher constructs an implement task, the agent's `mcp__forge__*` calls hit the GitLab adapter via `forge-mcp`. - [ ] Agent creates an MR. Reviewer is requested. Reviewer agent picks up, reads MR diff (`getPullRequestDiff` adapter call), submits APPROVE or REQUEST_CHANGES via `submitReview` (GitLab `approve` / `unapprove + discussion` mapping). - [ ] Boss merges the MR via `mergePullRequest` (GitLab squash). - [ ] Issue auto-closes (GitLab `Closes #N` keyword in MR body). ### Dashboard - [ ] The board renders the GitLab card alongside Forgejo cards under the same `Triage` / per-agent columns. PR pill renders correctly with GitLab CI state. Card click opens the side panel with MR diff link. ### Tests - [ ] Integration test against recorded GitLab REST fixtures (no live GitLab in CI) walks the entire dispatch loop. - [ ] Manual: one real issue on a real GitLab repo, watched and processed end-to-end. Capture command + screenshots in the closing PR description. ## Out of scope - GitHub end-to-end smoke (file separately if needed). - GitLab CI integration beyond reading pipeline status. - A second GitLab repo (one is enough to validate). ## References - `specs/forge-mcp-multi-forge.md` §Story FM-4 - `specs/multi-forge.md` §MF-7 — multi-forge dispatch tests, this extends - `apps/server/src/infrastructure/forge/gitlab-adapter.ts` - Depends on **FM-1**, **FM-2**, **FM-3**.
Collaborator

🤖 Auto-assigned to boss (heuristic: area:agents → boss (architecture-touching)). Reply /unassign to reroute.

🤖 Auto-assigned to **boss** (heuristic: area:agents → boss (architecture-touching)). Reply `/unassign` to reroute.
Author
Collaborator

Unassigned boss + wired native dependency on #694. CI-side coverage is done (PR #693), the remaining ACs (real GitLab project, dispatch-loop run, dashboard screenshots) are operator-side per docs/multi-forge.md §FM-4 and now tracked on #694. Reassign once #694 lands its evidence and this can close.

Unassigned boss + wired native dependency on #694. CI-side coverage is done (PR #693), the remaining ACs (real GitLab project, dispatch-loop run, dashboard screenshots) are operator-side per `docs/multi-forge.md` §FM-4 and now tracked on #694. Reassign once #694 lands its evidence and this can close.
Sign in to join this conversation.
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
charles/claude-hooks#655
No description provided.