Inställningar för distributionskällor
Installationsinställningarna som distributionskällor är beroende av — återanropsadresser, leverans av webhooks och standardvärden per leverantör — och vad du kontrollerar när pushar inte driftsätts.
Boundary-ägare ansluter distributionskällor själva — se Distributionskällor. Några inställningar i plattformens API avgör om de anslutningarna och deras webhooks kan fungera. De är miljövariabler för plattformens API; installern sätter de fyra första.
Inställningar
| Inställning | Installern sätter den till | Används för |
|---|---|---|
Deployments__GitHub__ApiBaseUrl |
https://api.example.com | GitHub-appens återanrops- och webhookadresser |
Deployments__GitLab__ApiBaseUrl |
https://api.example.com | GitLabs OAuth-omdirigerings-URI och projektens webhooks |
Deployments__AzureDevOps__ApiBaseUrl |
https://api.example.com | Azure DevOps OAuth-omdirigerings-URI och service hooks |
Deployments__FrontendUrl |
https://portal.example.com | Vart användare kommer tillbaka efter att ha anslutit en källa |
Deployments__GitLab__BaseUrl |
— | Den GitLab som används när en användare lämnar Base URL tomt. Standardvärdet i plattformens avbild är inte gitlab.com; sätt det till den GitLab som dina användare ansluter till |
Deployments__AzureDevOps__TenantId |
— | Den Entra ID-tenant som används när en användare lämnar Tenant ID tomt. Utan den avvisas en Azure DevOps-anslutning med OAuth utan tenant-ID |
De inbyggda värdena för inställningarna ApiBaseUrl i plattformens avbild pekar på localhost, så
en installation som inte sätter dem får återanrops- och webhookadresser som ingen Git-värd kan nå.
När en av dem är satt till ett tomt värde misslyckas anslutning av GitHub, eller av GitLab och Azure
DevOps med en OAuth-applikation, och byggen körs utan att webhooks registreras — plattformens API
loggar en varning om att de hoppades över.
Fasta adresser
| Adress | Vad som anropar den |
|---|---|
https://api.example.com/sources/gitlab/validate |
GitLab, som skickar tillbaka en användare som godkänt en OAuth-applikation |
https://api.example.com/sources/azure-devops/validate |
Microsoft Entra ID, som skickar tillbaka en användare som godkänt en appregistrering |
https://api.example.com/boundaries/<boundary-id>/sources/<provider>/webhooks |
Git-leverantören, som levererar push- och pull request-händelser |
Användarna registrerar de två återanropsadresserna i sina OAuth-applikationer. Webhookadressen
registreras av plattformen själv. Den kräver ingen inloggning: varje leverans autentiseras med
källans egen hemlighet — GitHubs signatur, GitLabs token-header, och för Azure DevOps HTTP
Basic-autentisering med användarnamnet stackship och hemligheten som lösenord.
När pushar inte driftsätts
- Git-värden måste nå https://api.example.com över HTTPS, med ett certifikat som den litar på.
- Autentiseringsuppgiften måste få skapa webhooks: en GitLab-token behöver rollen Maintainer i projektet.
- För Azure DevOps behöver användaren bakom token eller inloggningen behörigheterna Edit subscriptions och View subscriptions för projektets service hooks, som bara projektadministratörer har som standard.
- En webhook som plattformen inte kan skapa stoppar inte bygget och syns inte på källan: plattformens API loggar en varning och bygger ändå. Leta efter de varningarna när en källa bygger men aldrig driftsätts vid push.
- En GitHub-app behåller den webhookadress den skapades med. Om API:ets adress ändras måste befintliga GitHub-källor anslutas på nytt.
- Webhooks för GitLab och Azure DevOps skapas när plattformen bygger från projektet, så en källa som aldrig har byggts från har inga ännu.