Condividi tramite

Supporto per wildcard ed espressioni condizionali nei file di pipeline YAML

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

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

Azure Pipelines

Azure Repos

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.

Stato della compilazione

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 migliore pratica qui è prima far esaminare la modifica da uno dei collaboratori del repository e poi aggiungere un commento alla pull request 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 PR da un fork venga prima esaminata da un membro del team, è anche possibile applicare questo criterio solo ai contributi che hanno origine da non membri del team.

Con questo aggiornamento, è possibile ignorare la ricerca di commenti su una PR per i contributi ricevuti da qualsiasi collaboratore. Come non membro del team, quando si crea un fork e si crea una richiesta di pull verso l'upstream, non si è considerati un collaboratore del repository upstream finché la richiesta di pull non viene accettata. Una volta che la tua pull request è stata unita, sarai considerato 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 fusa la pull request, qualsiasi ulteriore contributo di un non membro del team attiverà direttamente la pipeline senza attendere un commento per la pull request.

Richiedere il commento di un membro del team prima di compilare una 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 riferimento a windows-2022 come immagine nella tua 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 riferimento a macos-11 come immagine nella tua pipeline.

pool:
  vmImage: macos-11

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 assicurarci che tutti siano a conoscenza di questa modifica, abbiamo pianificato 2 brevi interruzioni programmate ("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 TFVC sono ora generalmente disponibili.

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, potrebbero consentire a una pipeline (identità del servizio di build) di modificare il codice in quel branch. 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.

Tutte le impostazioni dei repository

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 dall'esprimere voti sulle loro PR a monte

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 pull request con le modifiche apportate all'upstream, gli utenti devono avere il permesso per contribuire alle pull request sull'upstream. Tuttavia, questo permesso determina anche chi può votare sui pull request nel repository upstream. Di conseguenza, è possibile trovarsi in situazioni in cui un utente, che non è un collaboratore del repository, può inviare una pull request e comportare l'unione a seconda dell'impostazione delle politiche di ramificazione.

Nelle organizzazioni che promuovono un modello di origine interna, fork-and-contribute è un modello comune. Per proteggere e promuovere ulteriormente questo modello, stiamo modificando il permesso di votare su una richiesta pull da "contribuire alle richieste pull" a "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 si fa affidamento su fork in Azure Repos.

Impostazioni repository

Passaggi successivi

Annotazioni

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à. Usa il menu di aiuto per segnalare un problema o fornire un suggerimento.

Inviare un suggerimento

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

Grazie,

Aaron Hallberg

  • Last updated on