Solución de problemas de ejecuciones de canalización

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

En este tema se proporcionan instrucciones generales para la solución de problemas. Para obtener una solución de problemas específica sobre .NET Core, consulte Solución de problemas de .NET Core.

Nota:

En Microsoft Team Foundation Server (TFS) 2018 y versiones anteriores, las canalizaciones de compilación y versión se denominan definiciones, las ejecuciones se denominan compilaciones, las conexiones de servicio se denominan puntos de conexión de servicio, las fases se denominan entornos y los trabajos se denominan fases.

Puede usar las secciones de solución de problemas siguientes para ayudar a diagnosticar problemas con la canalización. La mayoría de los errores de canalización se dividen en una de estas categorías.

La canalización no se desencadenará

Si una canalización no se inicia en absoluto, compruebe los siguientes problemas comunes relacionados con el desencadenador.

Nota:

Un motivo adicional por el que es posible que no se inicie es que la organización quede inactiva cinco minutos después de que el último usuario cierre la sesión de Azure DevOps. Después, cada una de las canalizaciones de compilación se ejecutará una vez más. Por ejemplo, mientras su organización está inactiva:

  • Una compilación nocturna de código en su organización se ejecutará solo una noche hasta que alguien inicie sesión de nuevo.
  • Las compilaciones de CI de otro repositorio de Git dejarán de ejecutarse hasta que alguien inicie sesión de nuevo.

La configuración de la interfaz de usuario invalida la configuración del desencadenador YAML

Las canalizaciones de YAML pueden invalidar su trigger configuración de desencadenador y pr en la interfaz de usuario de configuración de canalización. trigger Si los desencadenadores o pr no parecen activarse, compruebe esa configuración. Al editar la canalización, elija ... y, a continuación, Desencadenadores.

Pipeline settings UI

Compruebe la opción Invalidar el desencadenador YAML desde aquí para ver los tipos de desencadenador (integración continua o validación de solicitudes de incorporación de cambios) disponibles para el repositorio.

Override YAML trigger from here.

No se admiten desencadenadores de solicitud de incorporación de cambios con Azure Repos

pr Si el desencadenador no se activa y usa Azure Repos, se debe pr a que los desencadenadores no se admiten para Azure Repos. En Azure Repos Git, las directivas de rama se usan para implementar la validación de compilación de solicitudes de incorporación de cambios. Para más información, consulte Directiva de rama para la validación de solicitudes de incorporación de cambios.

Filtros de rama mal configurados en desencadenadores de CI y PR

Al definir un desencadenador de INTEGRACIÓN continua o PR de YAML, puede especificar cláusulas include y exclude para ramas y rutas de acceso. Asegúrese de que la include cláusula coincida con los detalles de la confirmación y que la exclude cláusula no las excluya.

Importante

Al definir un desencadenador de INTEGRACIÓN continua o PR de YAML, solo las ramas configuradas explícitamente para incluirse desencadenarán una ejecución. Las inclusión se procesan primero y, a continuación, se quitan de la lista. Si especifica una exclusión pero no especifica ninguna inclusión, no se desencadenará nada. Para obtener más información, consulte pr and trigger.

Al definir un desencadenador de INTEGRACIÓN continua o PR de YAML, puede especificar cláusulas include y exclude para ramas, etiquetas y rutas de acceso. Asegúrese de que la include cláusula coincida con los detalles de la confirmación y que la exclude cláusula no las excluya. Para obtener más información, consulte pr and trigger.

Nota:

Si especifica una exclude cláusula sin una include cláusula , equivale a especificar * en la include cláusula .

Conversiones de zona horaria de desencadenador programadas

Los desencadenadores programados de YAML se establecen mediante la zona horaria UTC. Si los desencadenadores programados no parecen activarse en el momento adecuado, confirme las conversiones entre utc y la zona horaria local, teniendo en cuenta también la configuración del día. Para obtener más información, consulte Desencadenadores programados.

La configuración de la interfaz de usuario invalida los desencadenadores programados de YAML

Si la canalización de YAML tiene desencadenadores programados de YAML y desencadenadores programados definidos por la interfaz de usuario, solo se ejecutan los desencadenadores programados definidos por la interfaz de usuario. Para ejecutar los desencadenadores programados definidos por YAML en la canalización de YAML, debe quitar los desencadenadores programados definidos en la interfaz de usuario de configuración de canalización.

Para acceder a la interfaz de usuario de configuración de canalización desde una canalización YAML, edite la canalización, elija ... y, a continuación, Desencadenadores.

Pipeline settings UI

Quite todos los desencadenadores programados.

Delete scheduled triggers in the Pipeline settings UI.

Una vez quitados todos los desencadenadores programados de la interfaz de usuario, se debe realizar una inserción para que los desencadenadores programados de YAML empiecen a ejecutarse. Para obtener más información, consulte Desencadenadores programados.

Colas de canalización, pero nunca obtiene un agente

Si la canalización pone en cola pero nunca obtiene un agente, compruebe los siguientes elementos.

Nota:

Los escenarios siguientes no consumirán un trabajo paralelo:

  • Si usa canalizaciones de versión o canalizaciones YAML de varias fases, una ejecución consume un trabajo paralelo solo cuando se implementa activamente en una fase. Aunque la versión está esperando una aprobación o una intervención manual, no consume un trabajo paralelo.
  • Cuando se ejecuta un trabajo de servidor o se implementa en un grupo de implementación mediante canalizaciones de versión, no se consumen trabajos paralelos.

Más información: Cómo una canalización consume un trabajo paralelo, Agregar aprobaciones previas a la implementación, Trabajos del servidor, Grupos de implementación

Límites de trabajos paralelos: no hay agentes disponibles o ha alcanzado los límites libres.

Si actualmente está ejecutando otras canalizaciones, es posible que no tenga ningún trabajo paralelo restante o que haya alcanzado los límites libres.

Para comprobar los límites, vaya a Project configuración, Trabajos paralelos.

Pipelines concurrent jobs

Después de revisar los límites, compruebe la simultaneidad para ver cuántos trabajos se están ejecutando actualmente y cuántos están disponibles.

Si actualmente está ejecutando otras canalizaciones, es posible que no tenga ningún trabajo paralelo restante o que haya alcanzado los límites libres.

No se puede acceder a Azure Key Vault detrás del firewall desde Azure DevOps

Si no puede acceder a Azure Key Vault desde la canalización, es posible que el firewall bloquee la dirección IP del agente de Azure DevOps Services. Las direcciones IP publicadas en el archivo JSON semanal deben incluirse en la lista de permitidos. Para obtener más información, consulte Agentes hospedados por Microsoft: Redes.

No tiene suficiente simultaneidad

Para comprobar la cantidad de simultaneidad que tiene:

  1. Para comprobar los límites, vaya a Project configuración, Trabajos paralelos.

    Concurrent pipeline limits

    También puede acceder a esta página; para ello, vaya a https://dev.azure.com/{org}/_settings/buildqueue?_a=concurrentJobso elija Administrar trabajos paralelos de los registros.

    Manage parallel jobs

  2. Determine en qué grupo desea comprobar la simultaneidad (grupos hospedados o autohospedados de Microsoft) y elija Ver trabajos en curso.

  3. Verá el texto que indica Trabajos X/X en ejecución actualmente. Si ambos números son los mismos, los trabajos esperarán hasta que se completen los trabajos en ejecución.

    View in-progress jobs

    Puede ver todos los trabajos, incluidos los trabajos en cola, seleccionando Grupos de agentes en la configuración de Project.

    View queued jobs

    En este ejemplo, el límite de trabajos simultáneos es uno, con un trabajo en ejecución y otro en cola. Cuando todos los agentes están ocupados ejecutando trabajos, como en este ejemplo, se muestra el siguiente mensaje cuando se ponen en cola trabajos adicionales: The agent request is not running because all potential agents are running other requests. Current position in queue: 1. En este ejemplo, el trabajo se encuentra a continuación en la cola, por lo que su posición es una.

Es posible que el trabajo esté esperando aprobación.

Es posible que la canalización no se mueva a la siguiente fase porque está esperando la aprobación. Para más información, consulte Definición de aprobaciones y comprobaciones.

Todos los agentes disponibles están en uso

Los trabajos pueden esperar si todos los agentes están ocupados actualmente. Para comprobar los agentes:

  1. Vaya a https://dev.azure.com/{org}/_settings/agentpools.

  2. Seleccione el grupo de agentes que se va a comprobar, en este ejemplo FabrikamPool y elija Agentes.

    Agent status

    En esta página se muestran todos los agentes actualmente en línea o sin conexión y en uso. También puede agregar agentes adicionales al grupo desde esta página.

Demandas que no coinciden con las funcionalidades de un agente

Si la canalización tiene demandas que no cumplen las funcionalidades de ninguno de los agentes, la canalización no se iniciará. Si solo algunos de los agentes tienen las funcionalidades deseadas y actualmente están ejecutando otras canalizaciones, la canalización se detendrá hasta que uno de esos agentes esté disponible.

Para comprobar las funcionalidades y demandas especificadas para los agentes y las canalizaciones, consulte la sección Funcionalidades.

Nota:

Las funcionalidades y demandas se suelen usar solo con agentes autohospedados. Si la canalización tiene demandas que no coinciden con las funcionalidades del sistema del agente, a menos que haya etiquetado explícitamente los agentes con funcionalidades coincidentes, las canalizaciones no obtendrán un agente.

Problemas de conexión del agente de TFS

Se produce un error en la configuración al probar la conexión del agente (solo TFS local)

Testing agent connection.
VS30063: You are not authorized to access http://<SERVER>:8080/tfs

Si se recibe el error anterior al configurar el agente, inicie sesión en el equipo de TFS. Inicie el administrador de Internet Information Services (IIS). Asegúrese de que la autenticación anónima está habilitada.

is TFS anonymous authentication enabled

Comunicación perdida del agente

Este problema se caracteriza por el mensaje de error:

The job has been abandoned because agent did not renew the lock. Ensure agent is running, not sleeping, and has not lost communication with the service.

Este error puede indicar que el agente perdió la comunicación con el servidor durante un intervalo de varios minutos. Compruebe lo siguiente para descartar la red u otras interrupciones en el equipo del agente:

  • Compruebe que las actualizaciones automáticas están desactivadas. Un reinicio de la máquina desde una actualización provocará un error de compilación o versión con el error anterior. Aplique actualizaciones de forma controlada para evitar este tipo de interrupción. Antes de reiniciar la máquina del agente, el agente debe marcarse primero deshabilitado en la página de administración del grupo y dejar que finalice la compilación en ejecución.
  • Compruebe que la configuración de suspensión está desactivada.
  • Si el agente se ejecuta en una máquina virtual, evite cualquier migración en vivo u otra operación de mantenimiento de máquina virtual que pueda afectar gravemente al estado de la máquina durante varios minutos.
  • Si el agente se ejecuta en una máquina virtual, las mismas recomendaciones de actualización del sistema operativo y las recomendaciones de configuración de suspensión se aplican a la máquina host. Además, cualquier otra operación de mantenimiento que afecte a la máquina host.
  • El registro del monitor de rendimiento u otro registro de métricas de estado puede ayudar a correlacionar este tipo de error con la disponibilidad de recursos restringida en el equipo del agente (disco, memoria, archivo de página, procesador, red).
  • Otra manera de correlacionar el error con problemas de red es hacer ping a un servidor indefinidamente y volcar la salida en un archivo, junto con las marcas de tiempo. Use un intervalo correcto, por ejemplo, 20 o 30 segundos. Si usa Azure Pipelines, le gustaría hacer ping a un dominio de Internet, por ejemplo, bing.com. Si usa un servidor TFS local, le gustaría hacer ping a un servidor en la misma red.
  • Compruebe que el rendimiento de red de la máquina es adecuado. Puede realizar una prueba de velocidad en línea para comprobar el rendimiento.
  • Si usa un proxy, compruebe que el agente está configurado para usar el proxy. Consulte el tema implementación del agente.

No se inició el agente de trabajo de TFS

Esto puede caracterizarse por un mensaje en la consola web "Esperando a que se solicite un agente". Compruebe que se ha iniciado el servicio TFSJobAgent (nombre para mostrar: Visual Studio Agente de trabajo en segundo plano de Team Foundation Windows).

Dirección URL de notificación mal configurada (versión del agente 1.x)

Esto se puede caracterizar por un mensaje en la consola web "Esperando la salida de la consola de un agente" y el proceso finalmente agota el tiempo de espera.

Una dirección URL de notificación que no coincide puede hacer que el trabajo no se pueda procesar para conectarse al servidor. Consulte Consola de administración de Team Foundation, nivel de aplicación. El agente 1.x escucha la cola de mensajes mediante la dirección URL con la que se configuró. Sin embargo, cuando se extrae un mensaje de trabajo de la cola, el proceso de trabajo usa la dirección URL de notificación para comunicarse con el servidor.

Comprobar Azure DevOps estado de una degradación del servicio

Compruebe Azure DevOps portal de estado del servicio en busca de problemas que puedan provocar una degradación del servicio, como un aumento del tiempo de cola para los agentes. Para obtener más información, consulte Azure DevOps Estado del servicio.

No se puede completar la canalización

Si la canalización obtiene un agente pero no se completa, compruebe los siguientes problemas comunes. Si el problema no parece coincidir con uno de estos, consulte Obtención de registros para diagnosticar problemas.

Tiempo de espera del trabajo

Una canalización se puede ejecutar durante mucho tiempo y, a continuación, producir un error debido al tiempo de espera del trabajo. El tiempo de espera del trabajo depende estrechamente del agente que se usa. Los agentes hospedados gratis de Microsoft tienen un tiempo de espera máximo de 60 minutos por trabajo para un repositorio privado y 360 minutos para un repositorio público. Para aumentar el tiempo de espera máximo de un trabajo, puede optar por cualquiera de las siguientes opciones.

  • Comprar un agente hospedado de Microsoft que le proporcionará 360 minutos para todos los trabajos, independientemente del repositorio usado.
  • Use un agente autohospedado para descartar cualquier problema de tiempo de espera debido al agente.

Obtenga más información sobre el tiempo de espera del trabajo.

Nota:

Si los trabajos del agente hospedado por Microsoft están agotando el tiempo de espera, asegúrese de que no ha especificado un tiempo de espera de canalización menor que el tiempo de espera máximo de un trabajo. Para comprobarlo, consulte Tiempos de espera.

Problemas al descargar código

Mi canalización produce un error en un paso de desprotección

Si usa un paso en un checkout repositorio de Git de Azure Repos de la organización que se encuentra en un proyecto diferente de la canalización, asegúrese de que el ámbito limitar la autorización del trabajo a la configuración del proyecto actual está deshabilitado o siga los pasos descritos en Identidades de compilación con ámbito para asegurarse de que la canalización tenga acceso al repositorio.

Cuando la canalización no pueda acceder al repositorio debido a un ámbito de autorización de trabajo limitado, recibirá el error Git fetch failed with exit code 128 y los registros contendrán una entrada similar 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.

Si la canalización produce un error inmediatamente con Could not find a project that corresponds with the repository, asegúrese de que el nombre del proyecto y del repositorio sean correctos en el checkout paso o en la declaración de recursos del repositorio.

problemas de Control de versiones de Team Foundation (TFVC)

Obtener orígenes que no descargan algunos archivos

Esto puede caracterizarse por un mensaje en el registro "Todos los archivos actualizados" del comando tf get . Compruebe que la identidad de servicio integrada tiene permiso para descargar los orígenes. La identidad Project servicio de compilación de recopilación o Project servicio de compilación necesitará permiso para descargar los orígenes, en función del ámbito de autorización seleccionado en la pestaña General de la canalización de compilación. En la interfaz de usuario web de control de versiones, puede examinar los archivos del proyecto en cualquier nivel de la jerarquía de carpetas y comprobar la configuración de seguridad.

Obtención de orígenes a través de Team Foundation Proxy

La manera más fácil de configurar el agente para obtener orígenes a través de un proxy de Team Foundation es establecer una variable TFSPROXY de entorno que apunte al servidor proxy TFVC para la ejecución del agente como usuario.

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 y Linux:

    export TFSPROXY=http://tfvcproxy:8081

Se produce un error en la canalización en un paso de línea de comandos, como MSBUILD.

Resulta útil restringir si un error de compilación o versión es el resultado de un problema de producto de Azure Pipelines/TFS (agente o tareas). Los errores de compilación y versión también pueden deberse a comandos externos.

Compruebe los registros de la línea de comandos exacta ejecutada por la tarea con errores. Intentar ejecutar el comando localmente desde la línea de comandos puede reproducir el problema. Puede resultar útil ejecutar el comando localmente desde su propia máquina o iniciar sesión en la máquina y ejecutar el comando como cuenta de servicio.

Por ejemplo, ¿se produce el problema durante la parte MSBuild de la canalización de compilación (por ejemplo, está usando la MSBuild o Visual Studio tarea De compilación)? Si es así, intente ejecutar el mismo comando MSBuild en un equipo local con los mismos argumentos. Si puede reproducir el problema en un equipo local, los pasos siguientes son investigar el problema MSBuild.

Diseño de archivo

La ubicación de herramientas, bibliotecas, encabezados y otras cosas necesarias para una compilación puede ser diferente en el agente hospedado que en el equipo local. Si se produce un error en una compilación porque no encuentra uno de estos archivos, puede usar los siguientes scripts para inspeccionar el diseño en el agente. Esto puede ayudarle a realizar un seguimiento del archivo que falta.

Cree una canalización yaML en una ubicación temporal (por ejemplo, un nuevo repositorio creado para solucionar problemas). Como se ha escrito, el script busca directorios en la ruta de acceso. Opcionalmente, puede editar la SEARCH_PATH= línea para buscar otros lugares.

# 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
      }
    }

Diferencias entre el símbolo del sistema local y el agente

Tenga en cuenta que algunas diferencias están en vigor al ejecutar un comando en un equipo local y cuando se ejecuta una compilación o versión en un agente. Si el agente está configurado para ejecutarse como un servicio en Linux, macOS o Windows, no se ejecuta en una sesión de inicio de sesión interactiva. Sin una sesión de inicio de sesión interactiva, existe la interacción de la interfaz de usuario y otras limitaciones.

Errores de uso de archivos o carpetas

Los errores de archivo o carpeta en uso a menudo se indican mediante mensajes de error como:

  • 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 [...]

Pasos para solucionar problemas:

Detección de archivos y carpetas en uso

En Windows, las herramientas como Monitor de procesos pueden ser capturar un seguimiento de eventos de archivo en un directorio específico. O bien, para una instantánea en el tiempo, se pueden usar herramientas como el Explorador de procesos o El identificador .

Exclusión antivirus

El examen de software antivirus de los archivos puede provocar errores de uso de archivos o carpetas durante una compilación o versión. Agregar una exclusión antivirus para el directorio del agente y configurar la "carpeta de trabajo" puede ayudar a identificar el software antivirus como proceso de interferencia.

MSBuild y /nodeReuse:false

Si invoca MSBuild durante la compilación, asegúrese de pasar el argumento /nodeReuse:false (formato /nr:falsecorto). De lo contrario, MSBuild procesos permanecerán en ejecución una vez completada la compilación. Los procesos permanecen durante algún tiempo en previsión de una posible compilación posterior.

Esta característica de MSBuild puede interferir con los intentos de eliminar o mover un directorio, debido a un conflicto con el directorio de trabajo del proceso de MSBuild.

Las tareas MSBuild y Visual Studio Compilación ya se agregan /nr:false a los argumentos pasados a MSBuild. Sin embargo, si invoca MSBuild desde su propio script, deberá especificar el argumento .

MSBuild y /maxcpucount:[n]

De forma predeterminada, las tareas de compilación, como MSBuild y Visual Studio compilar, ejecuten MSBuild con el /m modificador . En algunos casos, esto puede causar problemas como varios problemas de acceso a archivos de proceso.

Intente agregar el /m:1 argumento a las tareas de compilación para forzar que MSBuild ejecute solo un proceso cada vez.

Los problemas de uso de archivos pueden dar lugar al aprovechar la característica de proceso simultáneo de MSBuild. No especificar el argumento /maxcpucount:[n] (formato /m:[n]corto) indica a MSBuild usar un solo proceso. Si usa las tareas de MSBuild o de compilación Visual Studio, es posible que tenga que especificar "/m:1" para invalidar el argumento "/m" que se agrega de forma predeterminada.

Errores de MSBuild intermitentes o incoherentes

Si experimenta errores intermitentes o incoherentes MSBuild, intente indicar a MSBuild que use un solo proceso. Los errores intermitentes o incoherentes pueden indicar que la configuración de destino no es compatible con la característica de proceso simultáneo de MSBuild. Consulte MSBuild y /maxcpucount:[n].

El proceso deja de responder

El proceso deja de responder a las causas y los pasos de solución de problemas:

Esperando entrada

Un proceso que deja de responder puede indicar que un proceso está esperando la entrada.

La ejecución del agente desde la línea de comandos de una sesión de inicio de sesión interactiva puede ayudar a identificar si un proceso se solicita con un cuadro de diálogo para la entrada.

La ejecución del agente como servicio puede ayudar a eliminar los programas para solicitar la entrada. Por ejemplo, en .NET, los programas pueden depender del valor booleano System.Environment.UserInteractive para determinar si se debe solicitar. Cuando se ejecuta como un servicio de Windows, el valor es false.

Volcado de memoria del proceso

Analizar un volcado de memoria del proceso puede ayudar a identificar en qué espera un proceso interbloqueo.

Proyecto de WiX

La creación de un proyecto de WiX cuando los registradores de MSBuild personalizados están habilitados, puede hacer que WiX interbloquee esperando en el flujo de salida. Agregar el argumento /p:RunWixToolsOutOfProc=true MSBuild adicional solucionará el problema.

Finales de línea para varias plataformas

Al ejecutar canalizaciones en varias plataformas, a veces puede encontrar problemas con diferentes finales de línea. Históricamente, Linux y macOS usaban caracteres de salto de línea (LF) mientras que Windows usaban un retorno de carro más un salto de línea (CRLF). Git intenta compensar la diferencia haciendo que las líneas finalicen automáticamente en LF en el repositorio, pero CRLF en el directorio de trabajo en Windows.

La mayoría de las herramientas de Windows están bien con finales de solo LF, y este comportamiento automático puede causar más problemas de lo que resuelve. Si encuentra problemas basados en finales de línea, se recomienda configurar Git para que prefiera LF en todas partes. Para ello, agregue un .gitattributes archivo a la raíz del repositorio. En ese archivo, agregue la siguiente línea:

* text eol=lf

Variables que tienen ' (comilla simple) anexadas

Si la canalización incluye un script de Bash que establece variables mediante el ##vso comando , es posible que vea un adicional ' anexado al valor de la variable establecida. Esto ocurre debido a una interacción con set -x. La solución consiste en deshabilitar temporalmente set -x antes de establecer una variable. La sintaxis de Bash para hacerlo es set +x.

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

¿Por qué ocurre esto?

Muchos scripts de Bash incluyen el comando para ayudar con la set -x depuración. Bash rastreará exactamente qué comando se ejecutó y lo eco en stdout. Esto hará que el agente vea el ##vso comando dos veces y, la segunda vez, Bash habrá agregado el ' carácter al final.

Por ejemplo, considere esta canalización:

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

En stdout, el agente verá dos líneas:

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

Cuando el agente vea la primera línea, MY_VAR se establecerá en el valor correcto, "my_value". Sin embargo, cuando ve la segunda línea, el agente procesará todo al final de la línea. MY_VAR se establecerá en "my_value".

Las bibliotecas no se instalan para la aplicación python cuando se ejecuta el script

Cuando se implementa una aplicación de Python, en algunos casos, se ejecuta una canalización de CI/CD y el código se implementa correctamente, pero el archivo requirements.txt responsable de instalar todas las bibliotecas de dependencias no se ejecuta.

Para instalar las dependencias, use un script posterior a la implementación en la tarea de implementación App Service. En el ejemplo siguiente se muestra el comando que debe usar en el script posterior a la implementación. Puede actualizar el script para su escenario.

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

Para solucionar problemas relacionados con las conexiones de servicio, consulte Solución de problemas de conexión de servicio.

Habilite Explorador de Storage para implementar contenido estático como .css y .js en un sitio web estático desde Azure DevOps a través de Azure Pipelines

En este escenario, puede usar la tarea Copia de archivos de Azure para cargar contenido en el sitio web. Puede usar cualquiera de las herramientas descritas en Carga de contenido para cargar contenido en el contenedor web.

Obtención de registros para diagnosticar problemas

Si ninguna de las sugerencias anteriores coincide con el problema, puede usar la información de los registros para diagnosticar la canalización con errores.

Para empezar, examine los registros de la compilación o versión completadas. Para ver los registros, vaya al resumen de ejecución de canalización y seleccione el trabajo y la tarea. Si se ha generado un error en una tarea determinada, compruebe los registros de esa tarea.

Además de ver los registros en el resumen de compilación de la canalización, puede descargar registros completos que incluyen información de diagnóstico adicional y puede configurar registros más detallados para ayudar con la solución de problemas.

Para obtener instrucciones detalladas sobre cómo configurar y usar registros, consulte Revisión de registros para diagnosticar problemas de canalización.

Necesito más ayuda. Encontré un error. Tengo una sugerencia. ¿Adónde voy?

Obtención de la suscripción, la facturación y el soporte técnico

Notificar cualquier problema o enviar comentarios en Developer Community.

Agradecemos sus sugerencias: