Condividi tramite

Risolto più richieste dall'Developer Community

  • Articolo

In risposta al feedback, sono state classificate più funzionalità richieste nell'Developer Community. In Pipelines è stato aggiunto il supporto per la funzione di divisione stringa nell'espressione YAML. Inoltre, è ora possibile disabilitare la visualizzazione dell'ultimo messaggio di commit per un'esecuzione della pipeline. Nei piani di recapito è stato aumentato il limite del team da 15 a 20.

Per informazioni dettagliate, vedere le note sulla versione.

Azure Boards

Azure Pipelines

Azure Boards

Aumentare il limite del team dei piani di recapito da 15 a 20

I piani di recapito consentono di visualizzare più backlog e più team nell'organizzazione. In precedenza, è possibile visualizzare 15 backlog del team, tra cui una combinazione di backlog e team di progetti diversi. In questo sprint abbiamo aumentato il limite massimo compreso tra 15 e 20.

È stato risolto un bug nell'API Recupera elementi di lavoro per restituire il valore remotoUrl corretto per System.LinkTypes.Remote.Related i tipi di collegamento. Prima di questa correzione, è stato restituito il nome dell'organizzazione errato e un ID progetto mancante.

Correzioni di nuovi bug dell'hub di Schede

In questo sprint sono stati risolti più bug per New Boards Hub. È possibile visualizzare un elenco di correzioni di bug nel post di blog di aggiornamento di New Boards Hub, Sprint 209.

Azure Pipelines

Disabilitare la visualizzazione dell'ultimo messaggio di commit per un'esecuzione della pipeline

In precedenza, l'interfaccia utente pipeline usata per visualizzare l'ultimo messaggio di commit durante la visualizzazione dell'esecuzione di una pipeline.

Esempio di ultimo messaggio di commit

Questo messaggio può essere confuso, ad esempio quando il codice della pipeline YAML vive in un repository diverso da quello che contiene il codice che sta creando. Abbiamo sentito il feedback dell'Developer Community chiedendoci un modo per abilitare/disabilitare l'aggiunta del messaggio di commit più recente al titolo di ogni esecuzione della pipeline.

Con questo aggiornamento, è stata aggiunta una nuova proprietà YAML, denominata appendCommitMessageToRunName, che consente di eseguire esattamente questa operazione. Per impostazione predefinita, la proprietà è impostata su true. Quando lo si imposta su false, l'esecuzione della pipeline visualizzerà solo .BuildNumber

Esempio di esecuzione della pipeline con il numero di compilazione

Esempio di esecuzione della pipeline con l'ultimo messaggio di commit

Risorse e parametri del modello usati nell'API Rest delle pipeline

L'API REST eseguita da pipeline estese restituisce ora più tipi di artefatti usati da un'esecuzione della pipeline e i parametri usati per attivare tale esecuzione. È stata migliorata l'API per restituire le risorse e pipeline e i container parametri del modello usati in un'esecuzione della pipeline. È ora possibile scrivere controlli di conformità che valutano i repository, i contenitori e altre esecuzioni di pipeline usate da una pipeline.

Ecco un esempio del nuovo corpo della risposta.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Aggiungere il supporto per la funzione di divisione stringa nelle espressioni di modello YAML

Le pipeline YAML offrono modi pratici per ridurre la duplicazione del codice, ad esempio il ciclo attraverso each il valore di un elenco o di una proprietà di un oggetto.

A volte, il set di elementi da scorrere viene rappresentato come stringa. Ad esempio, quando l'elenco di ambienti da distribuire in è definito dalla stringa integration1, integration2.

Man mano che abbiamo ascoltato il feedback del Developer Community, abbiamo sentito che hai voluto una funzione stringa split nelle espressioni di modello YAML.

A questo scopo, è possibile split eseguire un'iterazione di una stringa e di eseguire each l'iterazione delle relative sottostringa.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Non sincronizzare i tag durante il recupero di un repository Git

L'attività di pagamento usa --tags l'opzione per recuperare il contenuto di un repository Git. In questo modo il server recupera tutti i tag e tutti gli oggetti a cui puntano i tag. Ciò aumenta il tempo per eseguire l'attività in una pipeline, in particolare se si dispone di un repository di grandi dimensioni con un numero di tag. Inoltre, l'attività di pagamento sincronizza i tag anche quando si abilita l'opzione di recupero superficiale, quindi eventualmente sconfiggendone lo scopo. Per ridurre la quantità di dati recuperati o estratti da un repository Git, è ora stata aggiunta una nuova opzione all'attività per controllare il comportamento dei tag di sincronizzazione. Questa opzione è disponibile sia nelle pipeline CLASSIC che YAML.

Questo comportamento può essere controllato dal file YAML o dall'interfaccia utente.

Per rifiutare esplicitamente la sincronizzazione dei tag tramite il file YAML, aggiungere l'oggetto fetchTags: false al passaggio di estrazione. Quando l'opzione fetchTags non è specificata, è uguale a se fetchTags: true usata.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Se si vuole modificare il comportamento delle pipeline YAML esistenti, potrebbe essere più pratico impostare questa opzione nell'interfaccia utente anziché aggiornare il file YAML. Per passare all'interfaccia utente, aprire l'editor YAML per la pipeline, selezionare Trigger, quindi Processo e quindi il passaggio Checkout.

Se si specifica questa impostazione sia nel file YAML che nell'interfaccia utente, il valore specificato nel file YAML ha la precedenza.

Per tutte le nuove pipeline create (YAML o Classic), i tag vengono ancora sincronizzati per impostazione predefinita. Questa opzione non modifica il comportamento delle pipeline esistenti. I tag verranno comunque sincronizzati in tali pipeline, a meno che non si modifica esplicitamente l'opzione come descritto in precedenza.

Aggiornamento della pianificazione brownout per le immagini ubuntu 18.04

Azure Pipelines deprecato l'immagine Ubuntu 18.04 (ubuntu-18.04) nei pool ospitati. Questa immagine verrà ritirata il 1° dicembre. È possibile iniziare a visualizzare tempi di coda più lunghi.

Per facilitare l'identificazione delle pipeline che usano l'immagine ubuntu-18.04, stiamo pianificando brownout. I processi avranno esito negativo durante un periodo di brownout.

  • I messaggi di avviso vengono visualizzati nelle esecuzioni della pipeline usando l'immagine ubuntu-18.04
  • Uno script è disponibile per trovare pipeline che usano immagini deprecate, tra cui ubuntu-18.04
  • Stiamo pianificando brevi "brownout". Tutte le esecuzioni ubuntu-18.04 avranno esito negativo durante il periodo di brownout. È pertanto consigliabile eseguire la migrazione delle pipeline prima dei brownout.

Pianificazione brownout (aggiornata)

  • 3 ottobre 12:00 UTC - 3 ottobre 14:00 UTC
  • 18 ottobre 14:00 UTC - 18 ottobre 16:00 UTC
  • 15 novembre 18:00 UTC - 15 novembre 20:00 UTC
  • 30 novembre 20:00 UTC - 30 novembre 22:00 UTC
  • 15 dicembre 20:00 UTC - 16 dicembre 00:00 UTC
  • 5 gennaio 10.00 UTC - 5 gennaio 14.00 UTC
  • 13 gennaio 12.00 UTC - 13 gennaio 16.00 UTC
  • 18 gennaio 14.00 UTC - 18 gennaio 18.00 UTC
  • 24 gennaio 16.00 UTC - 24 gennaio 20.00 UTC
  • 1 febbraio 18.00 UTC - 1 febbraio 22.00 UTC
  • 7 febbraio 16.00 UTC - 7 febbraio 22.00 UTC
  • 13 febbraio 14.00 UTC - 13 febbraio 22.00 UTC
  • 21 febbraio 10.00 UTC - 21 febbraio 22.00 UTC
  • 28 febbraio 10.00 UTC - 28 febbraio 22.00 UTC
  • 6 marzo 00.00 UTC - 7 marzo 00.00 UTC
  • 13 marzo 00.00 UTC - 14 marzo 00.00 UTC
  • 21 marzo 00.00 UTC - 22 marzo 00.00 UTC

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 cosa pensi di queste funzionalità. Usare il menu della Guida 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