Azure Pipelines - Aggiornamento Sprint 195

Funzionalità

Tentativi automatici per un'attività

Quando si dispone di un'attività instabile che fallisce intermittentemente in una pipeline, potrebbe essere necessario eseguire di nuovo la pipeline per farla riuscire. Nella maggior parte dei casi, il modo migliore per gestire un'attività o uno script non corretto consiste nel correggere l'attività o lo script stesso. Ad esempio, se l'attività di test non riesce in una pipeline a causa di test instabili, è sempre consigliabile correggere questi test e farli diventare più affidabili. Analogamente, se lo script non riesce una volta al tempo, è preferibile correggere lo script, ad esempio introducendo nuovi tentativi all'interno dello script.

Tuttavia, esistono alcuni casi in cui si potrebbe voler ripetere l'attività. Un caso d'uso comune è un'attività che scarica un pacchetto (ad esempio, NuGet, npm e così via). Si è spesso osservato che queste attività sono soggette a errori di rete e agli errori temporanei nei server di hosting del pacchetto. È stato ricevuto il feedback dell'utente che sarebbe preferibile ripetere automaticamente tali attività non riuscite senza dover riavviare nuovamente l'intera pipeline.

In base ai commenti e suggerimenti, è stata aggiunta una funzionalità per ripetere automaticamente un'attività in una pipeline in caso di errore. Se si usano pipeline YAML, è possibile impostare questo input come indicato di seguito:

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Quando si usano pipeline di compilazione o versione classiche, è possibile impostare questa proprietà nelle opzioni di controllo per l'attività.

Ecco alcuni aspetti da considerare quando si effettuano ripetizioni:

  • L'attività non riuscita viene ritentata immediatamente.
  • Non esiste alcun presupposto sulla idempotenza dell'attività. Se l'attività ha effetti collaterali (ad esempio, se ha creato parzialmente una risorsa esterna), potrebbe non riuscire la seconda volta che viene eseguita.
  • Non sono disponibili informazioni sul numero di tentativi reso disponibile per l'attività.
  • Viene aggiunto un avviso ai log attività che indica che non è riuscito prima di riprovare.
  • Tutti i tentativi di ripetizione di un'attività vengono visualizzati nell'interfaccia utente come parte dello stesso nodo attività.

Annotazioni

Richiede la versione dell'agente 2.194.0 o successiva. Non supportato per le attività senza agente.

Consumare gli input da un altro compito in un decorator

Di recente è stata aggiunta una funzionalità per inserire automaticamente un'attività in una pipeline prima di un'altra attività di destinazione in tale pipeline. Questa funzionalità viene ora migliorata consentendo di personalizzare il task iniettato usando i parametri di input dell'attività di destinazione. La sintassi per la scrittura di un elemento Decorator per eseguire questa operazione è la seguente:

{
    "contributions": [
        {
            "id": <my-required-task>,
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks",
                "ms.azure-pipelines-agent-job.post-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": <target-task-id>,
                "targettaskinputs": ["<name of input>"]
            }
        }
    ],
    ...
}

Questa funzionalità funziona solo quando si usa pre-task-tasks o post-task-tasks come destinazione per l'inserimento e si specifica nella targettask sezione delle proprietà del contributo. È quindi possibile aggiungere una proprietà aggiuntiva denominata targettaskinputs e specificare un elenco di nomi di parametri di input accettati dall'attività di destinazione. Questi input sono ora resi disponibili per l'attività inserita.

Un caso d'uso comune che può essere eseguito da tale scenario è il seguente. Si supponga di voler iniettare un'attività che loggherà automaticamente il nome dell'artefatto pubblicato durante una compilazione. Il nome dell'artefatto rappresenta un input per l'attività PublishBuildArtifacts. Il task iniettato può ora ottenere lo stesso parametro di input e usarlo per la creazione di log.

Miglioramenti alla cronologia di utilizzo delle connessioni al servizio

Quando una pipeline usa una connessione al servizio, tale utilizzo viene registrato nella cronologia della connessione. Gli amministratori della connessione al servizio possono esaminare la cronologia di utilizzo passando alle impostazioni del progetto e selezionando la connessione al servizio appropriata. Si sono verificati alcuni problemi con la cronologia di utilizzo delle connessioni al servizio risolte con questo aggiornamento. Le correzioni includono quanto segue:

  • Quando una connessione al servizio viene usata in un processo di distribuzione (invece di un normale processo), tale utilizzo non è stato registrato.
  • Se sono state usate più connessioni al servizio in più fasi di una pipeline, tutte le connessioni al servizio visualizzerebbero un record nella cronologia di utilizzo anche se alcune delle fasi sono state ignorate.

La specifica dell'agente predefinita per le pipeline classiche è ora Windows-2019

Nelle ultime note di rilascio è stato annunciato un piano di deprecazione per le immagini ospitate. In preparazione a tale operazione, la specifica dell'agente predefinita viene modificata durante la creazione di nuove pipeline nelle pipeline classiche in windows-2019.

Specifiche dell'agente

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.

  • Ultimo aggiornamento: