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 vergemakkelijken van codebeoordelingen en het beheren van codeverplaatsing binnen een opslagplaats. Branch-beleid dwingt codekwaliteit af tijdens het pull request-proces 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. Status van pull-aanvragen kan worden geïntegreerd in de workflow van pull-aanvragen en externe services toestaan op programmeerbare wijze goedkeuring te geven voor een codewijziging door eenvoudige informatie over succes- of faalstatus te koppelen aan een pull-aanvraag. Pull-aanvragen kunnen eventueel worden geblokkeerd totdat de externe service de wijziging goedkeurt.

Benodigdheden

Categorie	Vereisten
Toegang tot het project	Lid van een project.
toestemmingen	- Code weergeven in privéprojecten: ten minste Basis toegang. - Klonen of bijdragen aan code in privéprojecten: Lid van de Inzenders beveiligingsgroep of bijbehorende machtigingen in het project. - Machtigingen instellen voor vertakking of opslagplaats: Beheer machtigingen voor de vertakking of opslagplaats. - Standaardtak wijzigen: beleid bewerken machtigingen voor de opslagplaats. - Een opslagplaats importeren: Lid van de Projectbeheerders beveiligingsgroep of Git-projectniveau Opslagplaats maken machtiging ingesteld op Toestaan. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie.
Diensten	Repositories ingeschakeld.
Gereedschappen	Facultatief. Gebruik az repos opdrachten: Azure DevOps CLI.

Notitie

In openbare projecten hebben gebruikers met Stakeholder toegang tot volledige toegang tot Azure Repos, waaronder het weergeven, klonen en bijdragen aan code.

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

• status van pull-aanvraag: biedt een manier voor services om succes-/foutinformatie te koppelen aan een pull-aanvraag.
• Statusbeleid: biedt een mechanisme om de 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 de statussen van pull requests en hoe deze kunnen worden geïntegreerd in de PR-werkstroom.

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, failed, pending, notSet, notApplicableof error.
• 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?

Laten we eens kijken naar een voorbeeld. Overweeg een CI-service die nodig 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 Details-weergave van de pull request.

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

Status bijwerken

Een service kan een PR-status voor één PR bijwerken door extra statussen te plaatsen, waarvan alleen de meest recente wordt weergegeven voor elke unieke context. Door meerdere statussen te plaatsen, kunnen gebruikers verwachtingen beheren. Het plaatsen van een pending status is bijvoorbeeld een goede manier om te bevestigen dat een systeem een gebeurtenis heeft ontvangen en begint te werken. Het gebruik van een informatieve description zoals de volgende voorbeelden kan de gebruiker verder helpen begrijpen hoe het systeem werkt:

• Build in wachtrij
• Bouw in uitvoering
• Build geslaagd

Iteratiestatus

Wanneer de source-branch in een pull request 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 request een nieuwe status posten. Het posten van een status op een specifieke iteratie van een pull request garandeert dat die status alleen van toepassing is op de code die is geëvalueerd, en niet op toekomstige updates.

Notitie

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

Omgekeerd, als de status die wordt gepost van toepassing is op het volledige pull-verzoek, onafhankelijk van de code, 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 De status opnieuw instellen wanneer er nieuwe wijzigingen zijn. Dit garandeert verder dat de pull request pas kan worden gemerged zodra de meest recente iteratie de status van succeededheeft.

Zie de REST API-voorbeelden voor het plaatsen van de status op een iteratie en status op een pull request.

Statusbeleid

Door alleen de status te gebruiken, kunnen details van een externe dienst beschikbaar gesteld worden aan gebruikers binnen de PR-omgeving. Soms is het voldoende om informatie over een pull-aanvraag te delen, maar in andere gevallen moeten pull-aanvragen worden geblokkeerd totdat aan de vereisten is voldaan. Net als het standaardbeleid biedt het Statusbeleid een manier voor externe services om de voltooiing van PR's te blokkeren totdat aan de vereisten wordt voldaan. Als het beleid vereist is, moet het worden goedgekeurd om de pull request te voltooien. Als het beleid optioneel is, is het alleen informatief en is een status van succeeded niet vereist om de pull-aanvraag te voltooien.

Statusbeleid wordt geconfigureerd net als ander takbeleid . Wanneer u een nieuw statusbeleid toevoegt, moet de naam en 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 indeling genre/naam.

Wanneer een statusbeleid is opgegeven, vereist het dat er een status van succeeded aanwezig is met de context die overeenkomt met de geselecteerde naam om dit beleid goed te keuren.

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 Beleidstoepasselijkheid opties bepalen of dit beleid van toepassing is zodra een pull-aanvraag is gemaakt, of of het beleid pas van toepassing is nadat de eerste status op de pull-aanvraag is geplaatst.

1. Standaard toepassen: het beleid is van toepassing zodra de pull-aanvraag is gemaakt. Met deze optie gaat het beleid niet door na het aanmaken van de pull-aanvraag totdat een succeeded status is geplaatst. Een pull request kan vrijgesteld worden van het beleid door een status van notApplicablete plaatsen, en daarmee wordt de beleidsvereiste verwijderd.

2. Voorwaardelijk: het beleid is pas van toepassing zodra de eerste status op de pull request is geplaatst.

Deze opties kunnen samen worden gebruikt om een suite met dynamisch beleid te maken. Een orkestratiebeleid op het hoogste niveau kan standaard worden ingesteld, zodat het wordt toegepast terwijl de PR 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 orkestratiebeleid kan worden gemarkeerd als succeeded wanneer het klaar is met evalueren, of als notApplicable om aan de pull request aan te geven dat 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 Opnieuw opstarten toe te voegen aan het statusmenu waarmee tests worden geactiveerd. Als u een statusmenu wilt toevoegen, moet u het bijdragemodel gebruiken. Zie het Azure DevOps-extensievoorbeeldvoor 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