feat(integrations): push GitLab pipeline, deployment, release, and merge request events by webhook

Aperta
  • Qualcosa non va?
#428 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
22/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
gitlab, nextjs, playwright, typescript
Ambito
api, backend, documentation

Direzione di ricerca

Start with docs/providers/gitlab.md ("Permissions", "Permission risks") and the accepted contract from #28, then read src/lib/adapters/gitlab/ to see how the OAuth scopes and existing polling event types are shaped. The work spans token verification, webhook creation/deletion, deduplication on the delivery id header, and mapping payloads onto the existing event types, plus unit tests on recorded sanitized payloads and a Playwright spec for both setup paths. Done means both setup paths land a pipeline event in the timeline within a minute, a repeated delivery shows once, and npm run lint, npm run typecheck, npm test pass. Two unknowns are unresolved in the issue (delivery-id header stability, api vs read_api coexistence) and it depends on #28 and #426, so confirm those before starting.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: integrations blocked enhancement impact: medium priority: P1 size: M

Context

Decision on #424 (2026-11-14): GitLab offers automatic setup as an opt-in and setup by hand. GitLab has no read-only scope that can create a webhook: automatic setup needs api, which is read and write on every project the user can reach, while the adapter holds read_api (docs/providers/gitlab.md, "Permissions"). The panel in #426 warns about this before asking, and points users who want DevMacro to stay read-only to setup by hand.

Item Value
Create Project webhooks, one per project, through the API with api, or by hand in the project's Settings > Webhooks (Maintainer role). Group webhooks need a paid GitLab tier
Verification A secret token DevMacro generates, sent back in X-Gitlab-Token and compared in constant time. It is a shared secret, not a body signature
Events for the timeline Pipeline, deployment, release, and merge request events: the adapter's gitlab.pipeline.succeeded, gitlab.pipeline.failed, gitlab.deployment.succeeded, gitlab.deployment.failed, gitlab.release.published, gitlab.merge_request.merged
Not pushed Compute minutes and storage. Polling stays

Plan

  1. Declare GitLab's webhook in the #28 contract: automatic setup needs api, DevMacro generates the secret token, steps for setup by hand per project.
  2. Automatic: after the opt-in consent for api, create a project webhook with DevMacro's URL, the secret token, and the four event kinds on every project the connection reads. Delete them on disconnect. Projects added later get a webhook on the next sync.
  3. By hand: show the URL, the secret token, and the steps per project, and which projects have received a delivery.
  4. Verify X-Gitlab-Token, deduplicate on GitLab's per-delivery id header, map deliveries to the connection by the per-connection URL.
  5. Deliveries become the existing event types, so polling and webhooks show one entry.
  6. Docs: docs/providers/gitlab.md ("Permissions", "Permission risks" for api, "Webhooks", self-hosted registration with the api scope allowed on the OAuth app).

Acceptance criteria

  • The opt-in write access warning from #426 shows before GitLab's consent screen.
  • Automatic setup creates a webhook on each project, and a pipeline event reaches the timeline within a minute.
  • Setup by hand works per project without requesting api.
  • Disconnect deletes automatic webhooks.
  • A wrong or missing token is rejected and logged without the body; a repeated delivery is ignored.
  • An event seen by webhook and by polling shows once.
  • Unit tests on recorded, sanitized payloads from GitLab's documented samples. No live calls in CI.
  • Playwright e2e: both setup paths for the simulated GitLab provider.

Unverified

  • The header GitLab uses for a unique delivery id (X-Gitlab-Event-UUID or an idempotency header), and whether it is stable across retries.
  • Whether an api grant and a read_api grant for the same user and app can coexist, or the second replaces the first.

Files and areas

  • src/lib/adapters/gitlab/, docs/providers/gitlab.md, docs/operations/oauth-apps.md.
  • Non-goals: group webhooks, pushing compute minutes or storage.

Verification

  • npm run lint, npm run typecheck, npm test
  • Playwright spec for both setup paths.

Depends on

  • #28 Ingest provider webhooks
  • #426 Webhook setup panel

Branch: <issue-number>-gitlab-webhooks
Closes with a Closes #<issue-number> footer on the commit or pull request.

Model: anthropic/claude-opus-5-5 | Reasoning effort: unknown

Lingua principale
TypeScript
Stelle
1
Fork
1
Merge medio
6h 56m
PR unite (30g)
136

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eddiejaoude/StackDash

Tutte le issue di eddiejaoude/StackDash

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.