Risolvere i problemi di esecuzione delle pipeline

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Se l'esecuzione della pipeline non viene completata, è possibile usare le informazioni di diagnostica e i log forniti dalla pagina di riepilogo dell'esecuzione della pipeline per risolvere il problema.

Screenshot della pagina di riepilogo dell'esecuzione della pipeline.

Visualizzare i log

Selezionare il messaggio di errore per visualizzare i log per l'attività che non è riuscita a completare.

Screenshot del messaggio di errore dell'attività nella pagina di riepilogo dell'esecuzione della pipeline.

Viene visualizzata la pagina dei log con l'errore selezionato. In questo esempio si verifica un errore nell'attività cmd-line , in cui il echo comando viene immesso come ech.

Screenshot del log di diagnostica per l'esecuzione della pipeline.

È possibile visualizzare il log non elaborato per l'attività scegliendo Visualizza log non elaborato ed è possibile eseguire ricerche nel log usando Trova.

Screenshot delle opzioni di visualizzazione log in Azure DevOps.

Analizzare i log dell'attività non riuscita per ottenere informazioni sugli errori e indicazioni sul motivo per cui l'attività ha esito negativo. Per impostazione predefinita, i log nonverbose vengono generati da un'esecuzione della pipeline. Se i log predefiniti non indicano la causa del problema, è possibile ottenere altre informazioni configurando i log dettagliati.

Pagina di analisi degli errori

L'assistenza per la risoluzione dei problemi è disponibile tramite la pagina Analisi degli errori. Spostare il mouse sulla riga delle informazioni sull'errore e scegliere l'icona Visualizza analisi .

Screenshot dell'icona di analisi della visualizzazione nella pagina di riepilogo dell'esecuzione della pipeline.

Screenshot dell'icona di analisi della visualizzazione per Azure DevOps Server.

Scegliere Visualizza agente per gli agenti self-hosted (o Informazioni sull'immagine dell'agente ospitato per gli agenti ospitati da Microsoft) per visualizzare altre informazioni sull'agente usato per eseguire la pipeline e Visualizzare il log per visualizzare i log di esecuzione della pipeline.

Screenshot della pagina di analisi degli errori nel portale di Azure DevOps.

Scegliere il nome dell'attività sotto Dettagli di runtime per visualizzare informazioni sull'attività.

Screenshot dei dettagli dell'attività dall'analisi degli errori.

In questo esempio è possibile notare che si è verificato un errore in Value di .Script Scegliere Informazioni su questa attività per visualizzare la documentazione per l'attività.

Se il problema non è evidente dalla pagina di riepilogo dell'esecuzione della pipeline o dall'esplorazione dei log, vedere la sezione Problemi comuni seguenti e vedere Esaminare i log per diagnosticare i problemi della pipeline per informazioni sul download dei log completi che includono informazioni di diagnostica aggiuntive.

Problemi comuni

Informazioni dettagliate sulle attività per le esecuzioni di pipeline non riuscite

Azure DevOps fornisce un'impostazione di Task Insights per le esecuzioni di pipeline non riuscite, che, se abilitata, fornisce notifiche popup degli errori di compilazione con un collegamento per visualizzare un report.

Screenshot delle metriche delle informazioni dettagliate sulle attività.

Per configurare questa impostazione, passare a Funzionalità di anteprima, trovare Informazioni dettagliate attività per esecuzioni di pipeline non riuscite e scegliere l'impostazione desiderata.

Screenshot dell'impostazione delle informazioni dettagliate sulle attività per le esecuzioni della pipeline non riuscite.

Timeout dei processi

Una pipeline può essere eseguita per molto tempo e quindi non riesce a causa del timeout del processo. Il timeout del processo dipende da vicino dall'agente in uso. Gli agenti gratuiti ospitati da Microsoft hanno un timeout massimo di 60 minuti per processo per un repository privato e di 360 minuti per un repository pubblico. Per aumentare il timeout massimo per un processo, è possibile scegliere una delle opzioni seguenti.

  • Acquistare un agente ospitato da Microsoft che fornirà 360 minuti per tutti i processi, indipendentemente dal repository usato
  • Usare un agente self-hosted per escludere eventuali problemi di timeout dovuti all'agente

Altre informazioni sul timeout del processo.

Nota

Se si verifica il timeout dei processi dell'agente ospitato da Microsoft, assicurarsi di non aver specificato un timeout della pipeline inferiore al timeout massimo per un processo. Per verificare, vedere Timeout.

Problemi di download del codice

La pipeline ha esito negativo in un passaggio di estrazione

Se si usa un passaggio in un checkout repository Git Azure Repos nell'organizzazione che si trova in un progetto diverso da quello della pipeline, assicurarsi che l'impostazione Limita l'ambito di autorizzazione del processo all'impostazione di progetto corrente sia disabilitata o seguire i passaggi descritti in Identità di compilazione con ambito per assicurarsi che la pipeline abbia accesso al repository.

Quando la pipeline non riesce ad accedere al repository a causa di un ambito di autorizzazione del processo limitato, si riceverà l'errore Git fetch failed with exit code 128 e i log conterranno una voce simile a Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

Se la pipeline ha esito negativo immediatamente con Could not find a project that corresponds with the repository, assicurarsi che il progetto e il checkout nome del repository siano corretti nel passaggio o nella dichiarazione della risorsa del repository.

problemi di controllo della versione di Team Foundation (TFVC)

Ottenere origini che non scaricano alcuni file

Questo potrebbe essere caratterizzato da un messaggio nel log "Tutti i file aggiornati" dal tf get comando . Verificare che l'identità del servizio predefinita disponga dell'autorizzazione per scaricare le origini. Per scaricare le origini, a seconda dell'ambito di autorizzazione selezionato nella scheda Generale della pipeline di compilazione, sarà necessaria l'autorizzazione identity Project Collection Build Service o Project Build Service . Nell'interfaccia utente Web del controllo della versione è possibile esplorare i file di progetto a qualsiasi livello della gerarchia di cartelle e controllare le impostazioni di sicurezza.

Ottenere origini tramite il proxy di Team Foundation

Il modo più semplice per configurare l'agente per ottenere le origini tramite un proxy di Team Foundation è impostare la variabile TFSPROXY di ambiente che punta al server proxy TFVC per l'esecuzione dell'agente come utente.

Windows:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

macOS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

La pipeline ha esito negativo in un passaggio della riga di comando, ad esempio MSBUILD

È utile limitare se un errore di compilazione o versione è il risultato di un problema del prodotto Azure Pipelines/TFS (agente o attività). Gli errori di compilazione e rilascio possono anche derivare da comandi esterni.

Controllare i log per la riga di comando esatta eseguita dall'attività non riuscita. Il tentativo di eseguire il comando in locale dalla riga di comando potrebbe riprodurre il problema. Può essere utile eseguire il comando in locale dal computer e/o accedere al computer ed eseguire il comando come account del servizio.

Ad esempio, il problema si verifica durante la parte MSBuild della pipeline di compilazione( ad esempio, si usa l'attività MSBuild o Compilazione di Visual Studio)? In tal caso, provare a eseguire lo stesso comando MSBuild in un computer locale usando gli stessi argomenti. Se è possibile riprodurre il problema in un computer locale, i passaggi successivi consentono di analizzare il problema di MSBuild .

Layout del file

Il percorso di strumenti, librerie, intestazioni e altri elementi necessari per una compilazione potrebbe essere diverso nell'agente ospitato rispetto al computer locale. Se una compilazione non riesce perché non riesce a trovare uno di questi file, è possibile usare gli script seguenti per esaminare il layout nell'agente. Ciò potrebbe aiutare a rilevare il file mancante.

Creare una nuova pipeline YAML in un percorso temporaneo, ad esempio un nuovo repository creato per la risoluzione dei problemi. Come scritto, lo script cerca le directory nel percorso. Facoltativamente, è possibile modificare la SEARCH_PATH= riga per eseguire ricerche in altre posizioni.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Differenze tra il prompt dei comandi locale e l'agente

Tenere presente che alcune differenze sono effettive quando si esegue un comando in un computer locale e quando una compilazione o una versione è in esecuzione in un agente. Se l'agente è configurato per l'esecuzione come servizio in Linux, macOS o Windows, non viene eseguito all'interno di una sessione con accesso interattivo. Senza una sessione con accesso interattivo, esistono altre limitazioni per l'interazione dell'interfaccia utente.

Errori di file o cartelle in uso

File or folder in use gli errori sono spesso indicati da messaggi di errore, ad esempio:

  • Access to the path [...] is denied.
  • The process cannot access the file [...] because it is being used by another process.
  • Access is denied.
  • Can't move [...] to [...]

Passaggi per la risoluzione dei problemi:

Rilevare file e cartelle in uso

In Windows gli strumenti come Process Monitor possono essere per acquisire una traccia degli eventi di file in una directory specifica. In alternativa, per uno snapshot in tempo, è possibile usare strumenti come Esplora processi o Handle .

Esclusione antivirus

L'analisi software antivirus dei file può causare errori di utilizzo di file o cartelle durante una compilazione o una versione. L'aggiunta di un'esclusione antivirus per la directory dell'agente e la "cartella di lavoro" configurata può aiutare a identificare il software antivirus come processo di interferimento.

MSBuild e /nodeReuse:false

Se si richiama MSBuild durante la compilazione, assicurarsi di passare l'argomento /nodeReuse:false (forma /nr:falsebreve). In caso contrario, i processi MSBuild rimarranno in esecuzione al termine della compilazione. I processi rimangono per qualche tempo in previsione di una potenziale compilazione successiva.

Questa funzionalità di MSBuild può interferire con i tentativi di eliminare o spostare una directory, a causa di un conflitto con la directory di lavoro del processo MSBuild.

Le attività di compilazione di MSBuild e Visual Studio aggiungono /nr:false già agli argomenti passati a MSBuild. Tuttavia, se si richiama MSBuild dal proprio script, è necessario specificare l'argomento .

MSBuild e /maxcpucount:[n]

Per impostazione predefinita, le attività di compilazione, ad esempio MSBuild e Visual Studio Build , eseguono MSBuild con l'opzione /m . In alcuni casi questo può causare problemi, ad esempio problemi di accesso a più file di processo.

Provare ad aggiungere l'argomento alle attività di compilazione per forzare l'esecuzione /m:1 di MSBuild solo un processo alla volta.

I problemi relativi all'uso dei file possono comportare l'uso della funzionalità di processo simultaneo di MSBuild. Non specificando l'argomento /maxcpucount:[n] (forma /m:[n]breve) viene indicato a MSBuild di usare solo un singolo processo. Se si usano le attività di compilazione di MSBuild o Visual Studio, potrebbe essere necessario specificare "/m:1" per eseguire l'override dell'argomento "/m" aggiunto per impostazione predefinita.

Errori di MSBuild intermittenti o non coerenti

Se si verificano errori intermittenti o incoerenti di MSBuild, provare a indicare a MSBuild di usare un solo processo. Errori intermittenti o incoerenti potrebbero indicare che la configurazione di destinazione non è compatibile con la funzionalità di processo simultaneo di MSBuild. Vedere MSBuild e /maxcpucount:[n].

Il processo smette di rispondere

Il processo smette di rispondere alle cause e alla procedura di risoluzione dei problemi:

In attesa di input

Un processo che smette di rispondere potrebbe indicare che un processo è in attesa di input.

L'esecuzione dell'agente dalla riga di comando di una sessione interattiva con accesso potrebbe aiutare a identificare se un processo richiede un dialogo per l'input.

L'esecuzione dell'agente come servizio può aiutare a eliminare i programmi dalla richiesta di input. Ad esempio in .NET, i programmi possono basarsi sul valore booleano System.Environment.UserInteractive per determinare se richiedere o meno. Quando l'agente è in esecuzione come servizio Windows, il valore è false.

Dump del processo

L'analisi di un dump del processo può aiutare a identificare il processo in attesa di un deadlock.

Progetto WiX

La compilazione di un progetto WiX quando sono abilitati logger MSBuild personalizzati può causare il deadlock di WiX in attesa del flusso di output. L'aggiunta dell'argomento MSBuild aggiuntivo /p:RunWixToolsOutOfProc=true risolverà il problema.

Terminazioni di riga per più piattaforme

Quando si eseguono pipeline su più piattaforme, a volte è possibile riscontrare problemi con terminazioni di riga diverse. Storicamente, Linux e macOS usavano caratteri di avanzamento riga (LF) mentre Windows usava un ritorno a capo più un avanzamento riga (CRLF). Git tenta di compensare la differenza rendendo automaticamente le righe finali in LF nel repository, ma CRLF nella directory di lavoro in Windows.

La maggior parte degli strumenti di Windows funziona correttamente con le terminazioni solo LF e questo comportamento automatico può causare più problemi rispetto a quelli risolti. Se si verificano problemi in base alle terminazioni di riga, è consigliabile configurare Git per preferire LF ovunque. A tale scopo, aggiungere un .gitattributes file alla radice del repository. In tale file aggiungere la riga seguente:

* text eol=lf

Variabili con ' (virgolette singole) accodate

Se la pipeline include uno script Bash che imposta le variabili usando il ##vso comando , potrebbe essere visualizzato un ulteriore ' aggiunta al valore della variabile impostata. Ciò si verifica a causa di un'interazione con set -x. La soluzione consiste nel disabilitare temporaneamente set -x prima di impostare una variabile. La sintassi Bash per eseguire questa operazione è set +x.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Perché succede questo?

Molti script Bash includono il comando per facilitare il set -x debug. Bash traccerà esattamente il comando eseguito ed eseguirà l'eco a stdout. In questo modo l'agente visualizzerà il ##vso comando due volte e la seconda volta Bash aggiunse il ' carattere alla fine.

Si consideri ad esempio questa pipeline:

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

In stdout l'agente visualizzerà due righe:

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Quando l'agente vede la prima riga, MY_VAR verrà impostata sul valore corretto, "my_value". Tuttavia, quando vede la seconda riga, l'agente elabora tutto alla fine della riga. MY_VAR verrà impostato su "my_value".

Le librerie non vengono installate per l'applicazione Python quando viene eseguito lo script

Quando un'applicazione Python viene distribuita, in alcuni casi, viene eseguita una pipeline CI/CD e il codice viene distribuito correttamente, ma il file requirements.txt responsabile dell'installazione di tutte le librerie di dipendenze non viene eseguito.

Per installare le dipendenze, usare uno script di post-distribuzione nell'attività di distribuzione servizio app. Nell'esempio seguente viene illustrato il comando che è necessario usare nello script di post-distribuzione. È possibile aggiornare lo script per lo scenario.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Per risolvere i problemi relativi alle connessioni al servizio, vedere Risoluzione dei problemi di connessione al servizio.

Pipeline arrestata l'udito dall'agente

Se la pipeline ha esito negativo con un messaggio simile We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection.a , controllare l'utilizzo delle risorse dell'agente per verificare se il computer dell'agente sta esaurendo le risorse. A partire da Sprint 228, i log di Azure Pipelines contengono metriche di utilizzo delle risorse per ogni passaggio.

Quando si usa Azure DevOps Services, è possibile visualizzare l'utilizzo delle risorse nei log, tra cui l'utilizzo del disco, l'utilizzo della memoria e l'utilizzo della CPU, abilitando i log dettagliati. Al termine della pipeline, cercare nei log le voci per Agent environment resources ogni passaggio.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Per informazioni sull'acquisizione di altri log di utilizzo delle risorse, vedere Acquisire i dettagli sull'utilizzo delle risorse.

Abilitare Archiviazione Explorer per distribuire contenuto statico come .css e .js in un sito Web statico da Azure DevOps tramite Azure Pipelines

In questo scenario è possibile usare l'attività Copia file di Azure per caricare il contenuto nel sito Web. È possibile usare uno degli strumenti descritti in Caricamento del contenuto per caricare il contenuto nel contenitore Web.

Passaggi successivi