Ondersteuning voor jokertekens en voorwaardelijke expressies in YAML-pijplijnbestanden

  • Artikel

In deze sprint hebben we ondersteuning voor jokerkaarten en voorwaardelijke expressies opgenomen in YAML-pijplijnbestanden. Daarnaast hebben we meerdere updates aangebracht voor de door Azure Pipelines gehoste installatiekopieën.

Bekijk de volgende functiebeschrijvingen voor meer informatie.

Azure-pipelines

Azure-opslagplaatsen

Azure-pipelines

Nieuwe voorwaardelijke YAML-expressies

Het schrijven van voorwaardelijke expressies in YAML-bestanden is zojuist eenvoudiger geworden met het gebruik van ${{ else }} en ${{ elseif }} expressies. Hieronder ziet u voorbeelden van het gebruik van deze expressies in YAML-pijplijnenbestanden.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Ondersteuning voor jokertekens in padfilters

Jokerkaarten kunnen worden gebruikt bij het opgeven van insluitings- en uitsluitingsvertakkingen voor CI- of PR-triggers in een YAML-pijplijnbestand. Ze kunnen echter niet worden gebruikt bij het opgeven van padfilters. U kunt bijvoorbeeld niet alle paden opnemen die overeenkomen src/app/**/myapp*. Dit is opgemerkt als een ongemak door verschillende klanten. Deze update vult deze kloof. U kunt nu jokertekens (**, *of ?) gebruiken bij het opgeven van padfilters.

Ondersteuning voor meerdere statussen in Bitbucket

Azure Pipelines kan worden geïntegreerd met Bitbucket-opslagplaatsen en ondersteunt CI- en PR-triggers. U kunt meerdere pijplijnen instellen vanuit één Bitbucket-opslagplaats. Wanneer deze pijplijnen echter zijn voltooid, kunt u slechts één status in Bitbucket zien. We hebben feedback van de ontwikkelaarscommunity gehoord waarin wordt gevraagd om de status van elke pijplijn afzonderlijk in Bitbucket weer te geven. Met deze update hebben we onze API-aanroepen bijgewerkt naar Bitbucket en aanvullende informatie doorgegeven over de naam van de pijplijn.

Build status

Toestaan dat inzenders het opzoeken van PR-opmerkingen overslaan vóór de buildvalidatie

Wanneer u Azure Pipelines met GitHub-opslagplaatsen gebruikt, wordt u aangeraden niet automatisch een pull-validatiepijplijn uit te voeren voor bijdragen die zijn ontvangen van een geforkte opslagplaats. De best practice hier is om eerst een van de medewerkers van de opslagplaats de wijziging te controleren en vervolgens een opmerking toe te voegen aan de pull-aanvraag om de pijplijn te activeren. U kunt deze instellingen configureren door het menu Triggers (voor YAML-pijplijnen) of het tabblad Triggers (voor klassieke build-pijplijnen) in de pijplijnwebeditor te selecteren. In plaats van dat elke pull-aanvraag van een fork eerst moet worden gecontroleerd door een teamlid, kunt u dit beleid ook alleen afdwingen voor bijdragen die afkomstig zijn van niet-teamleden.

Met deze update kunt u doorgaan met het zoeken naar een pull-aanvraagopmerking van bijdragen die door een inzender zijn ontvangen. Als niet-teamlid, wanneer u een fork maakt en een pull-aanvraag voor de upstream maakt, wordt u pas als inzender beschouwd als inzender voor de upstream-opslagplaats totdat uw pull-aanvraag is samengevoegd. Zodra uw pull-aanvraag is samengevoegd, wordt u beschouwd als inzender. Als een niet-teamlid voor het eerst een pull-aanvraag indient vanuit een fork, moet iemand in uw team de pull-aanvraag controleren en een opmerking toevoegen om de pijplijn te activeren. Maar zodra de pull-aanvraag is samengevoegd, worden eventuele verdere bijdragen van dat niet-teamlid rechtstreeks geactiveerd zonder te wachten op een pull-aanvraagopmerking.

Require a team member's comment before building a pull request

Windows Server 2022 met Visual Studio 2022 is nu beschikbaar op door Microsoft gehoste agents (preview)

Windows Server 2022 en Visual Studio Enterprise 2022 Preview zijn nu beschikbaar in preview op door Microsoft gehoste agents. U kunt deze gebruiken door te windows-2022 verwijzen naar een afbeelding in uw pijplijn.

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

Wanneer u verwijst naar de meest recente windows-pool in uw YAML-pijplijnen, betekent dit nog steeds windows-2019 en niet windows-2022, terwijl de laatste in preview is.

De installatiekopieën van de Pijplijn voor Windows Server 2022 hebben verschillende hulpprogramma's en hulpprogrammaversies in vergelijking met Windows Server 2019. U kunt de details bekijken in het probleem met softwareaankondigingen en in de opslagplaats voor virtuele documentatieomgevingen.

Algemene beschikbaarheid van macOS 11 op door Microsoft gehoste agents

macOS 11 is nu algemeen beschikbaar op door Microsoft gehoste agents. U kunt deze gebruiken door te macos-11 verwijzen naar een afbeelding in uw pijplijn.

pool:
  vmImage: macos-11

De installatiekopieën van de macOS 11-pijplijn hebben verschillende hulpprogramma's en hulpprogramma's. Zie de volledige documentatie hier voor meer informatie over deze versie.

Installatiekopie van Ubuntu 16.04 verwijderen op door Microsoft gehoste agents

Zoals eerder aangekondigd, verwijderen we de Ubuntu 16.04-installatiekopie van door Microsoft gehoste agents op 20 september 2021. Traditionele ondersteuning van 5 jaar van Ubuntu 16.04 door Canonical is beëindigd in april 2021. U moet ubuntu-16.04-pijplijnen migreren naar ubuntu-18.04 of ubuntu-latest, die worden uitgevoerd op Ubuntu 20.04 LTS.

Builds die Ubuntu-16.04 gebruiken, hebben al een waarschuwing waarin ze worden aangemeld. Om ervoor te zorgen dat iedereen op de hoogte is van deze wijziging, hebben we 2 korte "brownouts" gepland. Ubuntu 16.04-builds mislukken tijdens de brownoutperiode. Daarom is het raadzaam om uw werkstromen vóór 6 september 2021 te migreren.

De brown-outs zijn gepland voor de volgende datums en tijden (houd er rekening mee dat deze zijn verlengd met een uur vanaf de eerder aangekondigde tijden): 6 september 2021 16:00 UTC – 10:00 UTC 14 september 2021 14:00 UTC – 10:00 UTC

Azure-opslagplaatsen

Nieuwe TFVC-pagina's zijn algemeen beschikbaar

We hebben verschillende pagina's in Azure DevOps bijgewerkt om een nieuw webplatform te gebruiken om de ervaring consistenter en toegankelijker te maken voor de verschillende services. TFVC-pagina's zijn bijgewerkt om het nieuwe webplatform te gebruiken. Deze wijzigingen zijn nu al enkele maanden in preview. Met deze update maken we de nieuwe TFVC-pagina's algemeen beschikbaar. Met deze update ziet u geen preview-functie met de naam 'Nieuwe TFVC-pagina's' meer in hun gebruikersinstellingen.

Vertakkingsmakers configureren om geen 'machtigingen beheren' op hun vertakkingen te krijgen

Wanneer u een nieuwe vertakking maakt, krijgt u 'Machtigingen beheren' voor die vertakking. Met deze machtiging kunt u de machtigingen van andere gebruikers wijzigen of aanvullende gebruikers toestaan om bij te dragen aan die vertakking. Een maker van een vertakking kan deze machtiging bijvoorbeeld gebruiken om een andere externe gebruiker toe te staan wijzigingen aan te brengen in de code. Of ze kunnen toestaan dat een pijplijn (service-identiteit bouwen) de code in die vertakking wijzigt. In bepaalde organisaties met hogere nalevingsvereisten mogen gebruikers dergelijke wijzigingen niet aanbrengen.

Met deze update kunt u alle en alle opslagplaatsen in uw teamproject configureren en ervoor zorgen dat makers van vertakkingen de machtiging Machtigingen beheren krijgen. Hiervoor gaat u naar de projectinstellingen, selecteert u Opslagplaatsen en Instellingen voor alle opslagplaatsen of een specifieke opslagplaats.

All repositories settings

Deze instelling is standaard ingeschakeld om het bestaande gedrag na te bootsen. U kunt deze functie echter uitschakelen als u deze nieuwe beveiligingsfunctie wilt gebruiken.

Voorkomen dat forkgebruikers stemmen op hun upstream-PRs

Met Azure-opslagplaatsen kunnen gebruikers met de machtiging Lezen voor een opslagplaats de opslagplaats splitsen en wijzigingen aanbrengen in hun fork. Als gebruikers een pull-aanvraag willen indienen met hun wijzigingen in de upstream, moeten gebruikers de machtiging 'bijdragen aan pull-aanvragen' voor de upstream. Deze machtiging bepaalt echter ook wie kan stemmen op pull-aanvragen in de upstream-opslagplaats. Als gevolg hiervan kunt u terechtkomen in situaties waarin een gebruiker, die geen bijdrager is aan de opslagplaats, een pull-aanvraag kan indienen en deze kan samenvoegen, afhankelijk van hoe u het vertakkingsbeleid instelt.

In organisaties die een inner-source model promoten, is fork-and-contribute een gemeenschappelijk patroon. Om dit patroon verder te beveiligen en te promoten, wijzigen we de machtiging om te stemmen op een pull-aanvraag van 'bijdragen aan pull-aanvragen' in 'bijdragen'. Deze wijziging wordt echter niet standaard doorgevoerd in alle organisaties. U moet zich aanmelden en een nieuw beleid selecteren in uw opslagplaats, 'Strict Vote Mode' genoemd om deze machtiging over te schakelen. U wordt aangeraden dit te doen als u afhankelijk bent van forks in Azure-opslagplaatsen.

Repository settings

Volgende stappen

Notitie

Deze functies worden de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en kijk eens.

Ga naar Azure DevOps

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

Make a suggestion

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Met vriendelijke groet,

Aaron Hallberg