FixControl levert goedgekeurde patches af bij vier soorten code-hosts. GitHub heeft zijn eigen aparte gids; deze pagina behandelt GitLab en Bitbucket. De flow is voor elke host gelijk: je klikt Run fix op een issue, een agent maakt een patch, de sandbox verifieert die, en zodra de patch is goedgekeurd gaat er een merge- of pull request open op een nieuwe branch. Alleen de manier van koppelen verschilt.
| Provider | Opent een | Hoe je koppelt |
|---|---|---|
| GitHub | Pull request | GitHub App installeren, device-code of personal access token |
| GitLab (gitlab.com) | Merge request | Inloggen met GitLab, of personal access token |
| GitLab (self-hosted) | Merge request | Personal access token met je GitLab-URL |
| Bitbucket Cloud | Pull request | Inloggen met Bitbucket, of access token / App Password |
| Bitbucket Server / Data Center | Pull request | Inrichten met je FixControl-contactpersoon (zie hieronder) |
Je moet admin van je FixControl-organisatie zijn om een code-host te koppelen. Alle verbindingen staan onder Instellingen → Kanalen → Code- & patch-levering.
GitLab
Inloggen met GitLab (aanbevolen voor gitlab.com)
- Open Instellingen → Kanalen → Code- & patch-levering → GitLab en klik op GitLab koppelen.
- Kies Inloggen met GitLab en klik op Doorgaan met GitLab.
- Bekijk op GitLab de gevraagde scopes (
apienread_user) en keur goed. - Je komt terug in FixControl en de verbinding staat op gekoppeld.
Merge requests worden toegeschreven aan jouw GitLab-gebruiker en tokens worden automatisch ververst. De OAuth-applicatie is van FixControl; je registreert er zelf geen.
Personal access token (self-hosted GitLab, of als alternatief)
Gebruik deze route voor een self-hosted GitLab-instance, of als je liever een token gebruikt dan inlogt.
- Maak in GitLab een personal access token aan met de scope
api. - Open in FixControl GitLab koppelen en kies Geavanceerd: plak een Personal Access Token.
- Vul voor een self-hosted instance de GitLab-URL in. Laat hem leeg voor gitlab.com.
- Plak het token en klik op Token opslaan.
Een token hoort bij de gebruiker die het heeft aangemaakt. Vertrekt die gebruiker of verloopt het token, dan stopt de levering tot iemand opnieuw koppelt.
Wat FixControl doet bij levering
- Maakt een nieuwe branch met een naam als
fix/<issue-key>-<slug>-…vanaf de branch van de codebase. - Commit de goedgekeurde patch op die branch.
- Opent een merge request met titel en beschrijving uit het issue.
- Merget nooit. Mergen blijft bij je team.
Webhooks
GitLab heeft één webhook-URL per project met een vinkje per eventtype, dus FixControl gebruikt er ook één: de CI/CD-webhook die je inricht via Instellingen → DevOps. Zie DevOps & CI/CD voor de exacte URL, welke events je aanzet en waar het geheim naartoe gaat. Vink Merge request events en Pipeline events aan op die webhook; er is geen tweede webhook nodig.
Wat elk event doet:
| GitLab-event | Wat FixControl ermee doet |
|---|---|
| Merge request | Werkt de afleverstatus van de patch bij wanneer zijn merge request wordt geopend, gesloten, gemerged of heropend, met wanneer hij gemerged is en door wie (of wanneer hij gesloten is). Een gemergede MR koppelt ook terug naar de externe registraties van het oorspronkelijke issue. |
| Pipeline | Twee lezingen van dezelfde aflevering, weggeschreven naar twee verschillende plekken: de CI/CD-lane bestuurt hem als pipeline-run voor deploymentgates, en de code-lane kopieert de samenvatting naar de CI-status van de patch. |
| Push, Note (opmerkingen) | Niet afgehandeld. Niets in FixControl reageert op een push of op een opmerking bij een merge request. |
Drie eigenschappen van dat pad zijn het weten waard, want ze zijn wat een webhook betrouwbaar maakt:
- Hij wordt geverifieerd, niet vertrouwd. De code-lane-lezing zoekt de koppeling opnieuw op en verifieert de handtekening opnieuw over dezelfde ruwe bytes die de CI/CD-lane verifieerde. Er gaat geen "al gecontroleerd"-vlag tussen de twee heen.
- Een herlevering is geen tweede effect. Elke lane claimt zijn eigen dedupsleutel, dus een aflevering die GitLab opnieuw stuurt wordt per lane hooguit één keer verwerkt.
- Een aflevering blijft binnen zijn eigen project, en status gaat niet achteruit. Een event kan geen patch van een ander project verplaatsen, en een laat binnenkomend ouder event kan een nieuwer event niet ongedaan maken.
De afleverstatus van de patch is niet de status van het FixControl-issue: de merge request mergen sluit het issue niet. Dat blijft een besluit dat iemand neemt.
Is er geen webhook ingericht, dan kun je de status van een merge request alsnog verversen met Controleren bij de patch.
Bitbucket Cloud
Inloggen met Bitbucket (aanbevolen)
- Open Instellingen → Kanalen → Code- & patch-levering → Bitbucket en klik op Bitbucket koppelen.
- Kies Inloggen met Bitbucket en klik op Doorgaan met Bitbucket.
- Keur op Bitbucket de gevraagde toegang tot repositories en pull requests goed.
- Je komt terug in FixControl en de verbinding staat op gekoppeld.
De OAuth consumer is van FixControl; je maakt er zelf geen aan.
Access token of App Password
- Maak in Bitbucket een workspace- of repository-access token aan (aanbevolen), of een App Password. Geef het lees- en schrijfrechten op repositories en pull requests.
- Open in FixControl Bitbucket koppelen en kies Geavanceerd: plak een access token of App Password.
- Plak het token. Vul bij een App Password ook de Bitbucket-gebruikersnaam in; laat die leeg bij een access token.
- Klik op Token opslaan.
Status van pull requests
Gemergede en afgewezen pull requests, en de buildstatus van commits, kunnen FixControl bereiken via een Bitbucket-webhook. Het webhook-geheim wordt door FixControl beheerd: vraag je FixControl-contactpersoon om de webhook-URL en het geheim als je dit wilt. Zonder webhook klik je op Controleren bij de patch om de status van een pull request te verversen.
Bitbucket Server / Data Center
FixControl kan patches afleveren bij Bitbucket Server en Data Center, maar daar is vandaag geen aparte kaart voor onder Instellingen → Kanalen. Neem contact op met je FixControl-contactpersoon om het in te richten. Houd dit bij de hand:
- De basis-URL van je instance, bijvoorbeeld
https://bitbucket.internal.acme/. FixControl moet die kunnen bereiken. - Een HTTP access token met leesrechten op het project en lees- en schrijfrechten op de repositories.
Meerdere providers in één organisatie
Je kunt elke combinatie van providers koppelen. Bijvoorbeeld: GitHub voor productrepositories, GitLab voor een interne tools-monorepo, Bitbucket voor een legacy-product. Elke codebase wijst precies één provider aan, en agents gebruiken bij een Run fix automatisch de juiste.
Veelvoorkomende fouten
| Symptoom | Oorzaak en oplossing |
|---|---|
De verbinding toont Herverbinden vereist, of 401 unauthorized bij levering | Token verlopen of ingetrokken. Koppel opnieuw via Instellingen → Kanalen → Code- & patch-levering. |
404 not found bij het openen van een merge- of pull request | De repository is verplaatst of de codebase wijst naar het verkeerde project. Controleer de instellingen van de codebase. |
403 forbidden bij push | Het token heeft geen schrijfrechten. Gebruik voor GitLab een token met de scope api; voor Bitbucket een token met schrijfrechten op de repository. Koppel opnieuw met de juiste rechten. |
| GitLab-webhookleveringen geven 401 | Het geheim in GitLab klopt niet. Gebruik Geheim roteren op de GitLab CI-kaart onder Instellingen → DevOps en plak het nieuwe geheim in GitLab. |
FAQ
Kan één repository meerdere providers gebruiken? Nee. Elke codebase verwijst naar precies één provider. Spiegel je een repository over meerdere hosts, kies dan de canonieke en laat de andere buiten FixControl daarvan syncen.
Worden tokens versleuteld opgeslagen? Ja. Elke credential (OAuth-tokens, refresh-tokens, personal access tokens, App Passwords) wordt met AES-256-GCM versleuteld voordat hij wordt opgeslagen.
Kan ik een credential vervangen zonder lopende patches kwijt te raken? Ja. Opnieuw koppelen vervangt de opgeslagen credential. Patches die al gepusht zijn blijven onaangetast; nieuwe leveringen gebruiken de nieuwe credential.
Gerelateerd: GitHub · Codebases · DevOps & CI/CD