Werkstromen voor pull-aanvragen aanpassen en uitbreiden met de status van de pull-aanvraag

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Pull-aanvragen zijn een uitstekend hulpmiddel voor het faciliteren van codebeoordelingen en het beheren van codeverplaatsing binnen een opslagplaats. Vertakkingsbeleid dwingt codekwaliteit af tijdens het pull-aanvraagproces door vereisten vast te stellen die moeten worden uitgevoerd voor elke codewijziging. Met deze beleidsregels kunnen teams veel aanbevolen procedures afdwingen met betrekking tot het controleren van code en het uitvoeren van geautomatiseerde builds, maar veel teams hebben aanvullende vereisten en validaties om uit te voeren op code. Azure Repos biedt statussen voor pull-aanvragen om deze individuele en aangepaste behoeften te dekken. Statussen van pull-aanvragen kunnen worden geïntegreerd in de pull-werkstroom en externe services toestaan programmatisch af te melden bij een codewijziging door eenvoudige informatie over het succes-/fouttype te koppelen aan een pull-aanvraag. Pull-aanvragen kunnen eventueel worden geblokkeerd totdat de externe service de wijziging goedkeurt.

Integratie in de pull-werkstroom omvat een aantal verschillende concepten:

• Status van pull-aanvraag : biedt een manier voor services om informatie over succes/fouten te koppelen aan een pull-aanvraag.
• Statusbeleid : biedt een mechanisme om voltooiing van pull-aanvragen te blokkeren totdat de status van de pull-aanvraag aangeeft dat deze is geslaagd.
• Aangepaste acties : biedt een manier om het statusmenu uit te breiden met behulp van Azure DevOps Services-extensies.

In dit onderwerp leert u meer over statussen van pull-aanvragen en hoe deze kunnen worden gebruikt om te integreren in de pull-aanvraagwerkstroom.

Status van pull-aanvraag

De status van de pull-aanvraag biedt een manier voor services om eenvoudige informatie over succes-/fouttypen te koppelen aan een pull-aanvraag met behulp van de Status-API. Een status bestaat uit vier belangrijke gegevens:

• Staat. Een van de volgende vooraf gedefinieerde statussen: succeeded, , pendingfailed, notSet, , of notApplicableerror.
• Beschrijving. Een tekenreeks die de status aan de eindgebruiker beschrijft.
• Context. Een naam voor de status, meestal een beschrijving van de entiteit die de status plaatst.
• URL. Een koppeling waar gebruikers meer informatie kunnen krijgen die specifiek is voor de status.

In wezen is de status de manier waarop een gebruiker of service de evaluatie plaatst over een pull-aanvraag en het antwoord biedt op vragen zoals:

• Voldoen de wijzigingen aan de vereisten?
• Waar vind ik meer informatie over wat ik moet doen om aan de vereisten te voldoen?

We kijken naar een voorbeeld. Overweeg een CI-service die vereist is om alle codewijzigingen in een project te bouwen. Wanneer die service de wijzigingen in een pull-aanvraag evalueert, moet deze de resultaten van de build en tests terugsturen. Voor wijzigingen die de build doorgeven, kan een status zoals deze worden gepost in de pull-aanvraag:

{
    "state": "succeeded",
    "description": "CI build succeeded",
    "context": {
        "name": "my-ci-system",
        "genre": "continuous-integration"
    },
    "targetUrl": "http://contoso.com/CI/builds/1"
}

Deze status wordt weergegeven aan de eindgebruiker in de weergave Details van pull-aanvraag:

• Het state wordt aan de gebruiker weergegeven met behulp van een pictogram (groen vinkje voor succeeded, rode X voor failed, een klok voor pending, en een rood ! voor error).
• De description knopinfo wordt naast het pictogram weergegeven en de context knopinfo is beschikbaar.
• Wanneer een targetUrl wordt toegepast, wordt de beschrijving weergegeven als een koppeling naar de URL.

Status bijwerken

Een service kan een pull-aanvraagstatus voor één pull-aanvraag bijwerken door aanvullende statussen te plaatsen, waarvan alleen de meest recente status wordt weergegeven voor elke unieke contextaanvraag. Door meerdere statussen te plaatsen, kunnen gebruikers verwachtingen beheren. Het plaatsen van een pending status is bijvoorbeeld een goede manier om aan de gebruiker te bevestigen dat een systeem een gebeurtenis heeft ontvangen en aan het werk gaat. Door gebruik te maken van een informatieve description , zoals de volgende voorbeelden, kan de gebruiker meer inzicht geven in de werking van het systeem:

• "Build queued"
• "Build in progress"
• "Build succeeded"

Iteratiestatus

Wanneer de bronvertakking in een pull-aanvraag wordt gewijzigd, wordt er een nieuwe iteratie gemaakt om de meest recente wijzigingen bij te houden. Services die codewijzigingen evalueren, willen bij elke iteratie van een pull-aanvraag een nieuwe status posten. Het plaatsen van de status op een specifieke iteratie van een pull-aanvraag garandeert dat de status alleen van toepassing is op de code die is geëvalueerd en geen van de toekomstige updates.

Notitie

Als de pull-aanvraag meer dan 100.000 gewijzigde bestanden bevat, worden iteraties niet ondersteund om prestatie- en stabiliteitsredenen. Dit betekent dat eventuele aanvullende wijzigingen in een dergelijke pull-aanvraag worden opgenomen, maar dat er geen nieuwe iteratie wordt gemaakt voor die wijziging. Elke poging om een status voor een niet-bestaande iteratie te maken, retourneert bovendien een fout.

Als de status die wordt gepost, echter van toepassing is op de volledige pull-aanvraag, kan het plaatsen van de iteratie overbodig zijn. Als u bijvoorbeeld controleert of de auteur (een onveranderbare pull-aanvraageigenschap) tot een specifieke groep behoort, hoeft deze slechts eenmaal te worden geëvalueerd en is de iteratiestatus niet nodig.

Wanneer u het statusbeleid configureert en de iteratiestatus wordt gebruikt, moeten de voorwaarden voor opnieuw instellen worden ingesteld op Status opnieuw instellen wanneer er nieuwe wijzigingen zijn. Dit garandeert verder dat de pull-aanvraag pas kan worden samengevoegd als de meest recente iteratie de status succeededheeft.

Zie de REST API-voorbeelden voor het posten van de status van een iteratie en een pull-aanvraag.

Statusbeleid

Alleen status gebruiken, details van een externe service kunnen worden verstrekt aan gebruikers binnen de pull-ervaring. Soms is het delen van informatie over een pull-aanvraag alles wat nodig is, maar in andere gevallen moeten PULL's worden geblokkeerd voordat aan de vereisten wordt voldaan. Net als bij het in-box-beleid biedt het statusbeleid een manier voor externe services om de voltooiing van pull-aanvragen te blokkeren totdat aan de vereisten wordt voldaan. Als het beleid is vereist, moet het worden doorgegeven om de pull-aanvraag te voltooien. Als het beleid optioneel is, is het alleen informatief en is er geen status succeeded vereist om de pull-aanvraag te voltooien.

Statusbeleidsregels worden net als andere vertakkingsbeleidsregels geconfigureerd. Wanneer u een nieuw statusbeleid toevoegt, moet de naam en het genre van het statusbeleid worden ingevoerd. Als de status eerder is gepost, kunt u deze kiezen in de lijst; als het een nieuw beleid is, kunt u de naam van het beleid typen in de indelingsgenrenaam/.

Wanneer een statusbeleid is opgegeven, moet een status met succeeded de context overeenkomende geselecteerde naam aanwezig zijn om dit beleid door te geven.

Een geautoriseerd account kan ook worden geselecteerd om te vereisen dat een specifiek account de autoriteit heeft om de status te posten die het beleid goedkeurt.

Toepasselijkheid van beleid

De opties voor toepasselijkheid van beleid bepalen of dit beleid van toepassing is zodra er een pull-aanvraag wordt gemaakt of of het beleid pas van toepassing is nadat de eerste status is gepost op de pull-aanvraag.

1. Standaard toepassen: het beleid is van toepassing zodra de pull-aanvraag is gemaakt. Met deze optie wordt het beleid pas doorgegeven nadat de pull-aanvraag is gemaakt totdat de succeeded status is geplaatst. Een pull-aanvraag kan worden gemarkeerd als vrijgesteld van het beleid door een status van notApplicablete plaatsen, waardoor de beleidsvereiste wordt verwijderd.

2. Voorwaardelijk : het beleid is pas van toepassing als de eerste status wordt geplaatst in de pull-aanvraag.

Deze opties kunnen samen worden gebruikt om een suite met dynamisch beleid te maken. Een indelingsbeleid op het hoogste niveau kan standaard worden ingesteld om toe te passen terwijl de pull-aanvraag wordt geëvalueerd voor toepasselijke beleidsregels. Als er vervolgens aanvullende voorwaardelijke beleidsregels worden bepaald om toe te passen (mogelijk op basis van specifieke build-uitvoer), kan de status worden geplaatst om ze vereist te maken. Dit indelingsbeleid kan worden gemarkeerd succeeded wanneer het klaar is met evalueren of kan worden gemarkeerd notApplicable om aan te geven aan de pull-aanvraag die het beleid niet van toepassing is.

Aangepaste acties

Naast vooraf gedefinieerde servicehookgebeurtenissen die de service kunnen activeren om de pr-status bij te werken, is het mogelijk om het statusmenu uit te breiden met behulp van Azure DevOps Services-extensies om triggeracties aan de eindgebruiker te geven. Als de status bijvoorbeeld overeenkomt met een testuitvoering die opnieuw kan worden gestart door de eindgebruiker, is het mogelijk om een menuopdracht Opnieuw opstarten te hebben voor het statusmenu waarmee tests worden geactiveerd om uit te voeren. Als u een statusmenu wilt toevoegen, moet u het bijdragemodel gebruiken. Zie het voorbeeld van de Azure DevOps-extensie voor meer informatie.

Volgende stappen

Meer informatie over de PR-status-API en bekijk de handleidingen:

• Een statusserver voor pull-aanvragen maken met Node.js
• Azure Functions gebruiken om aangepast vertakkingsbeleid te maken
• Een vertakkingsbeleid configureren voor een externe service