Supporto per caratteri jolly ed espressioni condizionali nei file della pipeline YAML

In questo sprint è stato incluso il supporto per caratteri jolly ed espressioni condizionali nei file della pipeline YAML. Sono stati inoltre apportati più aggiornamenti alle immagini ospitate di Azure Pipelines.

Per informazioni dettagliate, vedi le descrizioni seguenti delle funzionalità.

Azure Pipelines

• Nuove espressioni condizionali YAML
• Supporto per caratteri jolly nei filtri di percorso
• Supporto per più stati in Bitbucket
• Consentire ai collaboratori di ignorare la ricerca di commenti a richieste pull prima della convalida della build
• Windows Server 2022 con Visual Studio 2022 è ora disponibile in agenti ospitati da Microsoft (anteprima)
• Disponibilità generale di macOS 11 Big Sur sugli agenti ospitati da Microsoft
• Rimozione dell'immagine Ubuntu 16.04 sugli agenti ospitati da Microsoft

Azure Repos

• Nuove pagine di controllo della versione di Team Foundation disponibili a livello generale
• Configurare gli autori dei rami in modo che non ottengano "autorizzazioni di gestione" per i rispettivi rami
• Impedire agli utenti di fork di votare in merito alle rispettive richieste pull upstream

Azure Pipelines

Nuove espressioni condizionali YAML

La scrittura di espressioni condizionali nei file YAML è stata semplificata con l'uso di ${{ else }} espressioni e ${{ elseif }} . Di seguito sono riportati esempi di come usare queste espressioni nei file di pipeline YAML.

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

Supporto per caratteri jolly nei filtri di percorso

I caratteri jolly possono essere usati quando si specificano rami di inclusione ed esclusione per i trigger CI o PR in un file YAML della pipeline. Tuttavia, non possono essere usati quando si specificano i filtri di percorso. Ad esempio, non è possibile includere tutti i percorsi che corrispondono a src/app/**/myapp*. Questo è stato sottolineato come un inconveniente da parte di diversi clienti. Questo aggiornamento riempie questo vuoto. È ora possibile usare caratteri jolly (**, *o ?) quando si specificano i filtri di percorso.

Supporto per più stati in Bitbucket

Azure Pipelines si integra con i repository Bitbucket e supporta i trigger CI e PR. È possibile configurare più pipeline da un singolo repository Bitbucket. Tuttavia, al termine di queste pipeline, è possibile visualizzare solo uno stato in Bitbucket. È stato ricevuto feedback dalla community degli sviluppatori che chiede di visualizzare lo stato di ogni pipeline separatamente in Bitbucket. Con questo aggiornamento, le chiamate API sono state aggiornate a Bitbucket e sono state passate informazioni aggiuntive sul nome della pipeline.

Consentire ai collaboratori di ignorare la ricerca di commenti a richieste pull prima della convalida della build

Quando si usa Azure Pipelines con i repository GitHub, è consigliabile non eseguire automaticamente una pipeline di convalida della richiesta pull per i contributi ricevuti da un repository con fork. La procedura consigliata è prima di tutto avere uno dei collaboratori del repository per esaminare la modifica e quindi aggiungere un commento alla richiesta pull per attivare la pipeline. È possibile configurare queste impostazioni selezionando il menu Trigger (per le pipeline YAML) o la scheda Trigger (per le pipeline di compilazione classiche) nell'editor Web della pipeline. Invece di richiedere che ogni richiesta pull da un fork venga prima esaminato da un membro del team, è anche possibile applicare questo criterio solo ai contributi che hanno origine da membri non del team.

Con questo aggiornamento, è possibile ignorare la ricerca di un commento della richiesta pull dai contributi ricevuti da qualsiasi collaboratore. Come membro non del team, quando si crea un fork e si crea una richiesta pull a upstream, non si è considerati un collaboratore al repository upstream fino a quando la richiesta pull non viene unita. Una volta unita la richiesta pull, si verrà considerati un collaboratore. Selezionando la nuova opzione illustrata di seguito, quando un membro non del team invia una richiesta pull da un fork per la prima volta, un utente del team dovrà esaminare la richiesta pull e aggiungere un commento per attivare la pipeline. Tuttavia, una volta unita la richiesta pull, tutti gli altri contributi eseguiti dal membro non del team attiveranno direttamente la pipeline senza attendere un commento per la richiesta pull.

Windows Server 2022 con Visual Studio 2022 è ora disponibile in agenti ospitati da Microsoft (anteprima)

Windows Server 2022 e Visual Studio Enterprise 2022 Preview sono ora disponibili in anteprima negli agenti ospitati da Microsoft. È possibile usarlo facendo windows-2022 riferimento all'immagine nella 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'

Quando si fa riferimento al pool windows-latest nelle pipeline YAML, significa comunque windows-2019 e non windows-2022, mentre quest'ultimo è in anteprima.

L'immagine della pipeline di Windows Server 2022 include diversi strumenti e versioni degli strumenti rispetto a Windows Server 2019. È possibile visualizzare i dettagli nel problema relativo all'annuncio software e nel repository degli ambienti virtuali della documentazione.

Disponibilità generale di macOS 11 sugli agenti ospitati da Microsoft

macOS 11 è ora disponibile a livello generale sugli agenti ospitati da Microsoft. È possibile usarlo facendo macos-11 riferimento all'immagine nella pipeline.

pool:
  vmImage: macos-11

L'immagine della pipeline macOS 11 include strumenti e strumenti diversi. Per altre informazioni su questa versione, vedere la documentazione completa qui.

Rimozione dell'immagine Ubuntu 16.04 sugli agenti ospitati da Microsoft

Come annunciato in precedenza, l'immagine Ubuntu 16.04 verrà rimossa dagli agenti ospitati da Microsoft il 20 settembre 2021. Il supporto tradizionale di 5 anni di Ubuntu 16.04 da Canonical è terminato ad aprile 2021. Sarà necessario eseguire la migrazione delle pipeline ubuntu-16.04 a ubuntu-18.04 o ubuntu-latest che verrà eseguita in Ubuntu 20.04 LTS.

Le build che usano Ubuntu-16.04 hanno già un avviso che viene registrato. Per assicurarsi che tutti siano a conoscenza di questa modifica, abbiamo pianificato 2 brevi "brownouts". Le build ubuntu 16.04 avranno esito negativo durante il periodo di brownout. È quindi consigliabile eseguire la migrazione dei flussi di lavoro prima del 6 settembre 2021.

I brownout sono pianificati per le date e le ore seguenti (si noti che questi sono stati estesi di un'ora dall'orario annunciato in precedenza): 6 settembre 2021 4:00 UTC - 10:00 UTC 14 settembre 2021 4:00 UTC - 10:00 UTC

Azure Repos

Nuove pagine di controllo della versione di Team Foundation disponibili a livello generale

Sono state aggiornate diverse pagine in Azure DevOps per usare una nuova piattaforma Web con l'obiettivo di rendere l'esperienza più coerente e più accessibile nei vari servizi. Le pagine TFVC sono state aggiornate per usare la nuova piattaforma Web e queste modifiche sono state in anteprima per diversi mesi. Con questo aggiornamento, le nuove pagine TFVC sono disponibili a livello generale. Con questo aggiornamento non verrà più visualizzata una funzionalità di anteprima denominata "Nuove pagine TFVC" nelle impostazioni utente.

Configurare gli autori dei rami in modo che non ottengano "autorizzazioni di gestione" per i rispettivi rami

Quando si crea un nuovo ramo, si ottengono le "autorizzazioni di gestione" in tale ramo. Questa autorizzazione consente di modificare le autorizzazioni di altri utenti o di consentire ad altri utenti di contribuire a tale ramo. Ad esempio, un creatore di rami può usare questa autorizzazione per consentire a un altro utente esterno di apportare modifiche al codice. In alternativa, possono consentire a una pipeline (identità del servizio di compilazione) di modificare il codice in tale ramo. In alcune organizzazioni con requisiti di conformità più elevati, gli utenti non devono essere in grado di apportare tali modifiche.

Con questo aggiornamento, è possibile configurare tutti i repository nel progetto team e limitare i creatori di rami a ottenere l'autorizzazione "Gestisci autorizzazioni". A tale scopo, passare alle impostazioni del progetto, selezionare Repository e quindi Impostazioni per tutti i repository o un repository specifico.

Questa impostazione è attivata per impostazione predefinita per simulare il comportamento esistente. Tuttavia, è possibile disattivarlo se si vuole usare questa nuova funzionalità di sicurezza.

Impedire agli utenti di fork di votare in merito alle rispettive richieste pull upstream

Con Azure Repos, gli utenti con autorizzazione di "lettura" per un repository possono creare un fork del repository e apportare modifiche nel fork. Per inviare una richiesta pull con le modifiche apportate all'upstream, gli utenti devono "contribuire alle richieste pull" per l'upstream. Tuttavia, questa autorizzazione determina anche chi può votare le richieste pull nel repository upstream. Di conseguenza, è possibile terminare in situazioni in cui un utente, che non è un collaboratore al repository, può inviare una richiesta pull e far sì che venga unito a seconda della modalità di configurazione dei criteri di ramo.

Nelle organizzazioni che promuovono un modello di origine interna, fork-and-contribute è un modello comune. Per proteggere e promuovere ulteriormente questo modello, stiamo modificando l'autorizzazione per votare una richiesta pull da "contribuire alle richieste pull" per "contribuire". Tuttavia, questa modifica non viene apportata per impostazione predefinita in tutte le organizzazioni. È necessario acconsentire esplicitamente e selezionare un nuovo criterio nel repository, denominato "Strict Vote Mode" per cambiare questa autorizzazione. È consigliabile farlo se ci si basa su fork in Azure Repos.

Passaggi successivi

Nota

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Passare ad Azure DevOps

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usare il menu ? per segnalare un problema o fornire un suggerimento.

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Aaron Hallberg