Stöd för jokertecken och villkorsuttryck i YAML-pipelinefiler

I den här sprinten har vi inkluderat stöd för jokertecken och villkorsuttryck för YAML-pipelinefiler. Dessutom har vi gjort flera uppdateringar av Azure Pipelines-värdbaserade avbildningar.

Mer information finns i följande funktionsbeskrivningar.

Azure-pipelines

• Nya YAML-villkorsuttryck
• Stöd för jokertecken i sökvägsfilter
• Stöd för flera statusar i Bitbucket
• Låt deltagare hoppa över sökning av kommentarer för pull-begäranden före versionsvalidering
• Windows Server 2022 med Visual Studio 2022 är nu tillgängligt på Microsofts värdbaserade agenter (förhandsversion)
• Allmän tillgänglighet för macOS 11 Big Sur på Microsoft-värdbaserade agenter
• Borttagning av Ubuntu 16.04-avbildning på Microsoft-värdbaserade agenter

Azure-lagringsplatser

• Nya TFVC-sidor är allmänt tillgängliga
• Konfigurera så att grenskapare inte får ”Hantera behörigheter” på sina grenar
• Förhindra förgreningsanvändare från att rösta på sina uppströms pull-begäranden

Azure-pipelines

Nya YAML-villkorsuttryck

Det blev enklare att skriva villkorsuttryck i YAML-filer med hjälp av ${{ else }} och ${{ elseif }} uttryck. Nedan visas exempel på hur du använder dessa uttryck i YAML-pipelines-filer.

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

Stöd för jokertecken i sökvägsfilter

Jokertecken kan användas när du anger inkluderings- och exkluderingsgrenar för CI- eller PR-utlösare i en YAML-pipelinefil. De kan dock inte användas när du anger sökvägsfilter. Du kan till exempel inte inkludera alla sökvägar som matchar src/app/**/myapp*. Detta har påpekats som en olägenhet av flera kunder. Den här uppdateringen fyller det här tomrummet. Nu kan du använda jokertecken (**, *eller ?) när du anger sökvägsfilter.

Stöd för flera statusar i Bitbucket

Azure Pipelines integreras med Bitbucket-lagringsplatser och stöder CI- och PR-utlösare. Du kan konfigurera flera pipelines från en enda Bitbucket-lagringsplats. Men när dessa pipelines var klara kunde du bara se en status i Bitbucket. Vi hörde feedback från utvecklarcommunityn som bad om att få visa status för varje pipeline separat i Bitbucket. Med den här uppdateringen uppdaterade vi våra API-anrop till Bitbucket och skickar ytterligare information om namnet på pipelinen.

Låt deltagare hoppa över sökning av kommentarer för pull-begäranden före versionsvalidering

När du använder Azure Pipelines med GitHub-lagringsplatser rekommenderar vi att du inte automatiskt kör en PR-valideringspipeline för bidrag från en förgrenad lagringsplats. Bästa praxis här är att först låta en av samarbetspartnerna på lagringsplatsen granska ändringen och sedan lägga till en kommentar till PR för att utlösa pipelinen. Du kan konfigurera de här inställningarna genom att välja menyn Utlösare (för YAML-pipelines) eller fliken Utlösare (för klassiska byggpipelines) i pipelinewebbredigeraren. I stället för att kräva att varje PR från en förgrening först granskas av en gruppmedlem kan du även tillämpa den här principen endast på bidrag som kommer från icke-teammedlemmar.

Med den här uppdateringen kan du hoppa över att söka en PR-kommentar från bidrag som tas emot av någon deltagare. När du som icke-teammedlem skapar en förgrening och skapar en pr till den överordnade enheten betraktas du inte som en deltagare i den överordnade lagringsplatsen förrän din pr har slagits samman. När din PR har slagits samman betraktas du som deltagare. Genom att välja det nya alternativet som visas nedan, när en icke-teammedlem skickar en PR från en förgrening för första gången, skulle någon i ditt team behöva granska PR och lägga till en kommentar för att utlösa pipelinen. Men när PR har slagits samman utlöser eventuella ytterligare bidrag från den icke-teammedlemmen pipelinen direkt utan att vänta på en PR-kommentar.

Windows Server 2022 med Visual Studio 2022 är nu tillgängligt på Microsofts värdbaserade agenter (förhandsversion)

Windows Server 2022 och Visual Studio Enterprise 2022 Preview är nu tillgängliga som förhandsversion på Microsoft-värdbaserade agenter. Du kan använda den genom att referera till windows-2022 som avbildning i din pipeline.

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'

När du refererar till den senaste Windows-poolen i yaml-pipelines betyder det fortfarande windows-2019 och inte windows-2022, medan den senare är i förhandsversion.

Windows Server 2022-pipelinebilden har olika verktyg och verktygsversioner jämfört med Windows Server 2019. Du kan se informationen i programvarumeddelandeproblemet och i dokumentationens lagringsplats för virtuella miljöer.

Allmän tillgänglighet för macOS 11 på Microsoft-värdbaserade agenter

macOS 11 är nu allmänt tillgängligt på Microsoft-värdbaserade agenter. Du kan använda den genom att referera till macos-11 som avbildning i din pipeline.

pool:
  vmImage: macos-11

Borttagning av Ubuntu 16.04-avbildning på Microsoft-värdbaserade agenter

Som vi meddelade tidigare kommer vi att ta bort Ubuntu 16.04-avbildningen från Microsoft-värdbaserade agenter den 20 september 2021. Traditionellt 5-års stöd för Ubuntu 16.04 av Canonical avslutades i april 2021. Du måste migrera ubuntu-16.04-pipelines till ubuntu-18.04 eller ubuntu-latest som körs på Ubuntu 20.04 LTS.

Versioner som använder Ubuntu-16.04 har redan en varning som loggas in. För att se till att alla är medvetna om den här ändringen har vi schemalagt 2 korta "brownouts". Ubuntu 16.04-versioner misslyckas under brownout-perioden. Därför rekommenderar vi att du migrerar dina arbetsflöden före den 6 september 2021.

Brownouts är schemalagda för följande datum och tider (Observera att dessa har förlängts med en timme från de tidigare meddelade tiderna): 6 september 2021 16:00 UTC – 22:00 UTC 14 september 2021 16:00 UTC – 22:00 UTC

Azure-lagringsplatser

Nya TFVC-sidor är allmänt tillgängliga

Vi har uppdaterat olika sidor i Azure DevOps för att använda en ny webbplattform med målet att göra upplevelsen mer konsekvent och mer tillgänglig för de olika tjänsterna. TFVC-sidor har uppdaterats för att använda den nya webbplattformen, och dessa ändringar har varit i förhandsversion i flera månader nu. Med den här uppdateringen gör vi de nya TFVC-sidorna allmänt tillgängliga. Med den här uppdateringen ser du inte längre en förhandsgranskningsfunktion med namnet "Nya TFVC-sidor" i användarinställningarna.

Konfigurera så att grenskapare inte får ”Hantera behörigheter” på sina grenar

När du skapar en ny gren får du "Hantera behörigheter" för den grenen. Med den här behörigheten kan du ändra behörigheter för andra användare eller tillåta ytterligare användare att bidra till den grenen. En grenskapare kan till exempel använda den här behörigheten för att tillåta att en annan extern användare gör ändringar i koden. Eller så kan de tillåta att en pipeline (byggtjänstidentitet) ändrar koden i den grenen. I vissa organisationer med högre efterlevnadskrav bör användarna inte kunna göra sådana ändringar.

Med den här uppdateringen kan du konfigurera alla lagringsplatser i ditt teamprojekt och begränsa grenskapare från att få behörigheten "Hantera behörigheter". Det gör du genom att gå till projektinställningarna, välja Lagringsplatser och sedan Inställningar för alla lagringsplatser eller en specifik lagringsplats.

Den här inställningen är aktiverad som standard för att efterlikna det befintliga beteendet. Men du kan stänga av den om du vill använda den nya säkerhetsfunktionen.

Förhindra förgreningsanvändare från att rösta på sina uppströms pull-begäranden

Med Azure Repos kan användare med läsbehörighet på en lagringsplats förgrena lagringsplatsen och göra ändringar i sin förgrening. För att skicka en pull-begäran med sina ändringar i uppströms behöver användarna behörigheten "bidra till pull-begäranden" i uppströms. Den här behörigheten styr dock också vem som kan rösta på pull-begäranden på den överordnade lagringsplatsen. Därför kan du hamna i situationer där en användare, som inte är deltagare i lagringsplatsen, kan skicka en pull-begäran och göra så att den sammanfogas beroende på hur du konfigurerar förgreningsprinciperna.

I organisationer som främjar en modell för inre källor är förgrening och bidrag ett vanligt mönster. För att skydda och höja upp det här mönstret ytterligare ändrar vi behörigheten att rösta på en pull-begäran från "bidra till pull-begäranden" till "bidra". Den här ändringen görs dock inte som standard i alla organisationer. Du måste anmäla dig och välja en ny princip på lagringsplatsen med namnet "Strikt röstläge" för att växla den här behörigheten. Vi rekommenderar att du gör det om du förlitar dig på gafflarna i Azure Repos.

Nästa steg

Kommentar

Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.

Gå över till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om de här funktionerna. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Aaron Hallberg