Tillgängliga statuskontroller för pull-begäranden

Azure DevOps-tjänster

Statuskontroller framtvingar kvalitetsstandarder genom att blockera sammanslagningar tills testerna har godkänts, säkerhetsgenomsökningarna är klara eller andra villkor uppfylls. Azure DevOps Services och externa verktyg efter statuskontroller med hjälp av API:et för PR-status.

Om du vill kräva en statuskontroll som en grenprincip skapar du en princip i avsnittet Status för att kontrollera och anger kontrollens Genre och Namn i formatet genre/name. Pull-begäran blockerar sedan sammanslagningar tills kontrollen rapporterar succeeded.

Statusvärden och sammanslagningsbeteende

När en statuskontroll publicerar ett resultat i en pull-begäran rapporterar den något av följande värden:

Value Beteende med nödvändig princip Beteende med valfri princip
succeeded √ Avblockera policyn Informational
failed ✗ Blocksammanslagning Informational
error ✗ Blocksammanslagning Informational
pending ⏳ Blocksammanslagning (väntar på resultat) Informational
notApplicable √ Kringgår principkrav Informational
notSet ⏳ Behandlas som väntande Informational

Anmärkning

När en obligatorisk princip är inställd på Använd som standard kan du publicera notApplicable för att ta bort principkravet för en specifik PR utan att ändra principkonfigurationen. Detta är användbart när en kontroll inte gäller för en viss ändring.

Allmänna anvisningar om hur du lägger till en statuskontrollprincip finns i Konfigurera en grenprincip för en extern tjänst. Avancerade principalternativ, inklusive auktoriserade identitetsbegränsningar och inställningar för principtillämpbarhet, finns i Anpassa och utöka arbetsflöden för pull-begäranden med status för pull-begäranden.

Statuskontroller för första part Azure DevOps

Följande är de enda statuskontrollerna som har publicerats internt av Azure DevOps Services. Varje kontroll använder ett fast Genre-värde , så att du kan konfigurera grenprincipen före eller efter att tjänsten publicerar sin första status. Alla andra statuskontroller kommer från externa tjänster via API:et för PR-status.

GitHub Avancerad säkerhet för Azure DevOps

Dessa statuskontroller kräver GitHub Advanced Security för att Azure DevOps ska aktiveras på lagringsplatsen. Kontrollerna utvärderar säkerhetsrisker som identifierats i kodgenomsökning (CodeQL), beroendegenomsökning och hemlig genomsökning.

Genre Name Status att kontrollera Description
AdvancedSecurity AllHighAndCritical AdvancedSecurity/AllHighAndCritical Blocksammanslagningar när det finns en ouppklarad säkerhetsrisk eller hög allvarlighetsgrad på lagringsplatsen från alla genomsökningstyper (kod, beroende eller hemlighet). Kräver en byggverifieringsprincip med pipelineuppgifter för Avancerad säkerhet aktiverade.
AdvancedSecurity NewHighAndCritical AdvancedSecurity/NewHighAndCritical Blocksammanslagningar när pull-begäran introducerar nya kritiska eller allvarliga säkerhetsrisker från alla genomsökningstyper. Befintliga sårbarheter på lagringsplatsen blockerar inte sammanfogningen. Kräver en byggverifieringsprincip med pipelineuppgifter för avancerad säkerhet för att genomsöka PR-grenen.

Anmärkning

Båda AdvancedSecurity statuskontrollerna kräver en byggverifieringsprincip och avancerade säkerhetsgenomsökningsuppgifter som konfigurerats med Wait for Processing: true för att säkerställa att statusen återspeglar de senaste genomsökningsresultaten. För genomsökning av beroenden eller kodgenomsökning (CodeQL) aktiverar du Wait for Processing uppgiften AdvancedSecurity-Publish . För kodgenomsökning aktiverar du den också för AdvancedSecurity-CodeQL-Analyze uppgiften. Båda kontrollerna visas i listrutan Status för att kontrollera efter den första lyckade pipelinekörningen med avancerad säkerhetsgenomsökning.

Tip

Om lagringsplatsen har befintliga olösta aviseringar börjar du med AdvancedSecurity/NewHighAndCritical för att undvika att blockera alla pull-begäranden omedelbart. Migrera till AdvancedSecurity/AllHighAndCritical när aviseringsloggen har lösts.

Installationsinstruktioner finns i Konfigurera statuskontroller för pull-begäranden.

Important

Lämna Avancerade alternativ som standard när du konfigurerar statuskontrollprincipen. Om du ändrar den auktoriserade identiteten eller kräver ett iterations-ID förhindrar du att statuskontrollerna bokförs korrekt.

Azure-pipelines kodtäckning

Azure-pipelines publicerar automatiskt en statuskontroll för kodtäckning när en pipeline publicerar kodtäckningsresultat för en pull-begäran. Genren är pipelinenamnet, så det exakta genre/name värdet beror på hur du namngav din pipeline.

Genre Name Status att kontrollera Description
{pipeline-name} codecoverage {pipeline-name}/codecoverage Rapporterar diff-täckningsprocenten för rader som ändrats i pull-begäran. Rådgivning som standard; blockerar inte sammanslagningar om de inte har konfigurerats som en obligatorisk grenprincip med ett tröskelvärde för minsta täckning.

Standardtröskelvärdet för passering är 70% diff-täckning. Om du vill justera tröskelvärdet och andra inställningar lägger du till en azurepipelines-coverage.yml fil i roten på lagringsplatsen:

coverage:
  status:
    comments: on
    diff:
      target: 80

Ersätt 80 med önskad minsta diff-täckningsprocent.

Installationsinstruktioner finns i Framtvinga grenskydd med en kodtäckningsprincip.

Tip

Genren härleds från pipelinens visningsnamn i Azure-pipelines. Det är inte ett separat konfigurerbart värde. En pipeline med namnet CI – Main använder CI - Main/codecoverage till exempel som status för att kontrollera värdet. Statuskontroller visas endast i listrutan efter att tjänsten har publicerat minst en status till en pull-begäran. För nya integreringar som inte har körts ännu skriver du genre/name värdet direkt i fältet.

Anpassade och externa statuskontroller

Alla tjänster som använder PR-status-API :et kan skicka en statuskontroll till dina pull-begäranden. Om du vill publicera en statuskontroll via REST-API:et behöver den anropande identiteten behörigheten Bidra för att hämta begäranden på lagringsplatsen.

När en tjänst publicerar en status visas den genre/name i listrutan Status för att kontrollera när du lägger till en princip. För nya tjänster som inte har bokförts ännu skriver du värdet genre/name direkt.

Vanliga integrationsmönster

Integrationstyp Description Examples
Skapa och testa servrar Externa CI-verktyg som publicerar pass- eller fail-resultat efter att ha kört tester mot PR-grenen. Jenkins, GitLab CI, CircleCI, Travis CI
Kodkvalitetsanalys Statiska analysverktyg som söker igenom kod efter buggar, sårbarheter och kodlukt. SonarQube, SonarCloud
Säkerhetsskannrar Icke-Microsoft sårbarhetsskannrar som publicerar resultat efter genomsökning av PR-ändringar. Stöder även SARIF-formatresultat. Snyk, Checkmarx, WhiteSource (Mend), Microsoft Security DevOps
Efterlevnad och princip Verktyg för principframtvingande som verifierar licensiering, kodstandarder, regelkrav eller distributionsberedskap. Anpassade efterlevnadskontroller, distributionsportar, licensskannrar
GitHub Actions Kontroller från GitHub Actions arbetsflöden visas i Azure DevOps pr när lagringsplatsen är ansluten till GitHub. Se Azure DevOps GitHub integrering för konfigurationsinformation. Alla GitHub Actions arbetsflöden kan publicera status
Godkännanden och grindar Tjänster som kräver manuellt eller automatiserat godkännande innan sammanslagningar tillåts. ServiceNow, anpassade godkännandetjänster via REST API

Konfigurationsalternativ för principer

När du lägger till en statuskontrollprincip kan du konfigurera:

  • Principkrav: Ställ in principen efter behov (blockerar sammanslagningar om inte kontrollen godkänns) eller valfritt (endast information).
  • Auktoriserad identitet: Begränsa vilka konton som kan publicera statusvärden som uppfyller principen. Lämna tomt för att tillåta alla konton.
  • Återställningsvillkor: Ange om statusen återställs när en ny incheckning skickas. Som standard återställer push-överföring av en ny incheckning nödvändiga statuskontroller till väntande, vilket tvingar dem att utvärdera din senaste kod. Om du vill tillåta att en status bevaras mellan incheckningar inaktiverar du Återställningsstatus när nya ändringar görs.
  • Princip tillämplighet: Välj om principen ska tillämpas omedelbart (Tillämpa som standard) eller först efter att den första statusen har publicerats (villkorsstyrd).
    • Använd som standard: Principblocken sammanfogas tills en succeeded status har bokförts. Du kan publicera notApplicable för att kringgå kravet på en specifik PR.
    • Villkorsstyrd: Principen blir bara aktiv efter att kontrollen har bokfört sin första status.
  • Sökvägsfilter: Begränsa principen till PR:ar som ändrar filer i specifika sökvägar (valfritt).

Information om hur du implementerar en anpassad statuskontroll finns i:

Relaterat innehåll

  • Last updated on