Distributionskällor

En distributionskälla ansluter en boundary till en Git-leverantör eller ett privat containerregister. Resurser i den boundaryn kan sedan byggas från dess förråd eller hämta dess avbilder; resurser i andra boundaries kan inte använda den.

Distributionskällor hör till boundaryn: öppna Inställningar → Boundaries i sidomenyn, välj boundaryn och öppna dess flik Distributionskällor.

Åtgärd	Tillåter	Innehas av
kernel/deployments/read	Se boundaryns källor	Owner, Contributor; Apps Reader, Apps Operator, Functions Operator, Blueprints Operator
kernel/deployments/write	Ansluta en källa	Owner, Contributor
kernel/deployments/delete	Radera en källa	Owner, Contributor

Lägg till en källa

Välj Lägg till källa och välj leverantör. Guiderna för App Service och Static Web Apps erbjuder också Anslut driftsättningskälla, men att ansluta GitLab eller Azure DevOps med en OAuth-applikation lämnar sidan du är på — anslut dem från boundaryn innan du startar en guide.

GitHub

1. Ange eventuellt en GitHub Organization för att ansluta en organisation i stället för ditt personliga konto. Du måste vara inloggad på GitHub, och för en organisation vara en av dess ägare.
2. Välj Continue to GitHub. GitHub öppnas i en ny flik och skapar en privat GitHub-app för den här boundaryn.
3. Installera appen och välj, på GitHub, om den får nå alla förråd eller bara utvalda.

Appen kan läsa förrådens innehåll och tar emot deras push- och pull request-händelser.

GitLab

Välj OAuth App eller Access Token, och fyll i Base URL med adressen till din GitLab — till exempel https://gitlab.com, eller https://gitlab.yourcompany.com för en GitLab som du driver själv. Lämnas fältet tomt använder plattformen den GitLab-adress som är konfigurerad för din installation.

• Access Token — ange en Access Token med omfången api och read_repository och välj Connect with Token. En grupp- eller projekttoken behöver rollen Maintainer.
• OAuth App — registrera först en OAuth-applikation i GitLab med omdirigerings-URI:n https://api.example.com/sources/gitlab/validate och omfången api och read_repository. Ange dess Application ID och Application Secret, välj Connect to GitLab och godkänn begäran i GitLab.

Källan når de projekt som autentiseringsuppgiftens användare är medlem i.

Azure DevOps

Välj OAuth App eller Personal Access Token.

• Personal Access Token — ange Organization URL, exakt https://dev.azure.com/<organization>, och en Personal Access Token med minst omfånget Code (Read), och välj Connect with Token. Azure DevOps Server stöds inte.
• OAuth App — skapa först en appregistrering i Microsoft Entra ID med omdirigerings-URI:n https://api.example.com/sources/azure-devops/validate. Ange dess Application ID, Application Secret och Tenant ID, och välj Connect to Azure DevOps. Lämna Tenant ID tomt bara om din plattformsadministratör har konfigurerat en standardtenant. Källan använder den första organisation som ditt Microsoft-konto tillhör.

Källan når alla förråd i organisationen.

För att pushar ska driftsättas behöver Azure DevOps-användaren bakom token eller inloggningen även behörigheterna Edit subscriptions och View subscriptions för service hooks i varje projekt som plattformen bygger från; som standard har bara projektadministratörer dem. Utan dem ansluts källan och bygger, men plattformen kan inte registrera sina service hooks, så pushar startar aldrig något bygge.

Privat register

1. Välj Privat register.
2. Register — bara värdnamnet, till exempel ghcr.io, inte en URL. Lämna det tomt för Docker Hub.
3. Användarnamn och Lösenord eller token. Lösenordet lagras krypterat och visas aldrig igen.
4. Välj Anslut register.

En boundary har en autentiseringsuppgift per registervärd. För att byta lösenord ansluter du samma register igen: den nya uppgiften ersätter den gamla. Containrar som redan körs fortsätter att använda den tidigare uppgiften tills de driftsätts om.

Visa en källa

Välj en källa i listan för att se dess status, förrådsåtkomst, installations-ID och de förråd den når. För GitLab-källor visar Token Health om autentiseringsuppgiften är Healthy, Expiring Soon (mindre än 14 dagar kvar), Expired eller Revoked; det kontrolleras en gång om dagen.

Radera en källa

Använd raderingsåtgärden på källans rad och skriv dess installations-ID för att bekräfta. För ett privat register är installations-ID:t värdnamnet skrivet med bindestreck, till exempel ghcr-io.

Att radera återkallar det som plattformen kan återkalla — GitHub-appens installation, GitLab-OAuth-tokens — och tar bort autentiseringsuppgiften från plattformen. Det städar inte hos leverantören: själva GitHub-appen, och de webhooks som plattformen lagt till i GitLab-projekt och Azure DevOps, finns kvar tills du tar bort dem där. Resurser som byggs från källan kan inte längre byggas.

Använd en källa

Var	Vad den använder
App Service — guiden för att skapa, steget Distributionskälla — se Skapa en app	Ett GitHub-, GitLab- eller Azure DevOps-förråd och en gren. Alternativet Container tar en publik avbild; appar kan inte hämta från ett privat register.
Static Web Apps — guiden för att skapa, steget Källkod — se Skapa en statisk webbapp	Ett GitHub-, GitLab- eller Azure DevOps-förråd och en gren
Container Instances — steget Avbildning — se Välj avbilden	En avbild från ett privat register
Blueprints — en parameter av typen DeploymentSource	Ett privat register
Katalogkällor för blueprints — se Lägg till en katalogkälla	Ett GitHub-, GitLab- eller Azure DevOps-förråd som innehåller blueprints

Funktioner använder inte distributionskällor. En app eller statisk webbapp kan byta leverantör, förråd eller gren senare under Konfiguration → Distributionskälla.

Automatiska driftsättningar

En push till ett anslutet förråd bygger om, vid den pushade committen, varje app som byggs från det förrådet och vars gren — eller någon av vars platsers gren — matchar, och varje statisk webbapp som byggs från det förrådet och den grenen. För en app ersätter pushen också en version som du låst med Distribuera om den här versionen. Det finns inget att slå på: plattformen registrerar webhooken själv — för GitHub som en del av GitHub-appen, för GitLab och Azure DevOps på projektet när den bygger från det.

Om pushar aldrig startar ett bygge, kontrollera att autentiseringsuppgiften får skapa webhooks — för GitLab rollen Maintainer i projektet, för Azure DevOps behörigheterna för service hooks ovan. Driftsätt annars för hand och be din plattformsadministratör kontrollera plattformens inställningar för den leverantören.

Manuella driftsättningar

• App Service: Distribuera, eller Omdistribuera, på appen eller en plats — kräver apps/write.
• Static Web Apps: Driftsätt — kräver staticwebapp/deploy.
• Container Instances: Distribuera om på en komponent — kräver containerinstance/write.