Referencia de esquema de YAML
Azure Pipelines
Este artículo es una guía de referencia detallada para Azure Pipelines canalizaciones YAML. Incluye un catálogo de todas las funcionalidades de YAML admitidas y las opciones disponibles.
La mejor manera de empezar a trabajar con las canalizaciones de YAML es leer la guía de inicio rápido. Después de eso, para obtener información sobre cómo configurar la canalización de YAML para sus necesidades, consulte temas conceptuales como Generar variables yTrabajos.
Para obtener información sobre cómo configurar la canalización de YAML para sus necesidades, consulte temas conceptuales como Build variables (Generar variables) y Jobs (Trabajos).
Estructura de canalización
Una canalización es una o varias fases que describen un proceso de CI/CD. Las fases son las divisiones principales de una canalización. Las fases "Compilar esta aplicación", "Ejecutar estas pruebas" e "Implementar en preproducción" son buenos ejemplos.
Una fase es uno o varios trabajos, que son unidades de trabajo asignables a la misma máquina. Tanto las fases como los trabajos se pueden organizar en gráficos de dependencias. Algunos ejemplos son "Ejecutar esta fase antes de esa" y "Este trabajo depende de la salida de ese trabajo".
Un trabajo es una serie lineal de pasos. Los pasos pueden ser tareas, scripts o referencias a plantillas externas.
Esta jerarquía se refleja en la estructura de un archivo YAML como:
- Canalización
- Fase A
- Trabajo 1
- Paso 1.1
- Paso 1.2
- ...
- Trabajo 2
- Paso 2.1
- Paso 2.2
- ...
- Trabajo 1
- Fase B
- ...
- Fase A
Las canalizaciones simples no requieren todos estos niveles. Por ejemplo, en una compilación de un solo trabajo puede omitir los contenedores para fases y trabajos porque solo hay pasos. Y dado que muchas de las opciones que se muestran en este artículo no son necesarias y tienen valores predeterminados buenos, es poco probable que las definiciones de YAML las incluyan todas.
Una canalización es uno o varios trabajos que describen un proceso de CI/CD. Un trabajo es una unidad de trabajo asignable a la misma máquina. Puede organizar los trabajos en gráficos de dependencia como "Este trabajo depende de la salida de ese trabajo".
Un trabajo es una serie lineal de pasos. Los pasos pueden ser tareas, scripts o referencias a plantillas externas.
Esta jerarquía se refleja en la estructura de un archivo YAML como:
- Canalización
- Trabajo 1
- Paso 1.1
- Paso 1.2
- ...
- Trabajo 2
- Paso 2.1
- Paso 2.2
- ...
- Trabajo 1
Para las canalizaciones de un solo trabajo, puede omitir el contenedor de trabajos porque solo hay pasos. Y dado que muchas de las opciones que se muestran en este artículo no son necesarias y tienen valores predeterminados buenos, es poco probable que las definiciones de YAML las incluyan todas.
Convenciones
Estas son las convenciones de sintaxis que se usan en este artículo:
- A la izquierda de
:hay una palabra clave literal que se usa en las definiciones de canalización. - A la derecha de
:hay un tipo de datos. El tipo de datos puede ser de un tipo primitivo, como string, o una referencia a una estructura enriquecida definida en otra parte de este artículo. - El tipo de
[[]indica una matriz del tipo de datos mencionado. Por ejemplo,[ string ]es una matriz de cadenas. - El tipo de
{{::}indica una asignación de un tipo de datos a otro. Por ejemplo,{ string: string }es una asignación de cadenas a cadenas. - El símbolo
|indica que hay varios tipos de datos disponibles para la palabra clave . Por ejemplo,job | templateReferencesignifica que se permite una definición de trabajo o una referencia de plantilla.
Aspectos básicos de YAML
En este documento se trata el esquema de un Azure Pipelines archivo YAML.
Para obtener información sobre los conceptos básicos de YAML, consulte Learn YAML in Y Minutes (Aprender YAML en minutos Y).
Azure Pipelines no admite todas las características de YAML.
Las características no admitidas incluyen delimitadores, claves complejas y conjuntos.
Además, a diferencia de YAML estándar, Azure Pipelines depende de ver , , o un acceso directo de tarea como la primera clave stagejob de una taskscript asignación.
Canalización
name: string # build numbering format
resources:
pipelines: [ pipelineResource ]
containers: [ containerResource ]
repositories: [ repositoryResource ]
variables: # several syntaxes, see specific section
trigger: trigger
pr: pr
stages: [ stage | templateReference ]
Si tiene una sola fase ,puede omitir la palabra clave y especificar directamente la palabra clave jobs:
# ... other pipeline-level keywords
jobs: [ job | templateReference ]
Si tiene una sola fase y un único trabajo, puede omitir las palabras clave y y stages especificar directamente la palabra clave jobsstages
# ... other pipeline-level keywords
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
name: string # build numbering format
resources:
containers: [ containerResource ]
repositories: [ repositoryResource ]
variables: # several syntaxes, see specific section
trigger: trigger
pr: pr
jobs: [ job | templateReference ]
Si tiene un único trabajo, puede omitir la palabra clave y jobs especificar directamente la palabra clave jobs
# ... other pipeline-level keywords
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
Más información sobre:
- Pipelines con varios trabajos
- Contenedores y repositorios en canalizaciones
- Desencadenadores
- Variables
- Formatos de número de compilación
Fase
Una fase es una colección de trabajos relacionados.
De forma predeterminada, las fases se ejecutan secuencialmente.
Cada fase se inicia solo una vez completada la fase anterior, a menos que se especifique lo contrario a través de la dependsOn propiedad .
Use comprobaciones de aprobación para controlar manualmente cuándo debe ejecutarse una fase. Estas comprobaciones se usan normalmente para controlar las implementaciones en entornos de producción.
Las comprobaciones son un mecanismo disponible para el propietario del recurso. Controlan cuándo una fase de una canalización consume un recurso. Como propietario de un recurso como un entorno, puede definir las comprobaciones necesarias antes de que se pueda iniciar una fase que consuma el recurso.
Actualmente, las comprobaciones de aprobación manuales se admiten en entornos. Para obtener más información, vea Aprobaciones.
stages:
- stage: string # name of the stage (A-Z, a-z, 0-9, and underscore)
displayName: string # friendly name to display in the UI
dependsOn: string | [ string ]
condition: string
variables: # several syntaxes, see specific section
jobs: [ job | templateReference]
Obtenga más información sobre las fases, las condicionesy las variables.
Trabajo
Un trabajo es una colección de pasos ejecutados por un agente o en un servidor. Los trabajos se pueden ejecutar condicionalmente y pueden depender de trabajos anteriores.
jobs:
- job: string # name of the job (A-Z, a-z, 0-9, and underscore)
displayName: string # friendly name to display in the UI
dependsOn: string | [ string ]
condition: string
strategy:
parallel: # parallel strategy; see the following "Parallel" topic
matrix: # matrix strategy; see the following "Matrix" topic
maxParallel: number # maximum number of matrix jobs to run simultaneously
continueOnError: boolean # 'true' if future jobs should run even if this job fails; defaults to 'false'
pool: pool # see the following "Pool" schema
workspace:
clean: outputs | resources | all # what to clean up before the job runs
container: containerReference # container to run this job inside of
timeoutInMinutes: number # how long to run the job before automatically cancelling
cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
variables: # several syntaxes, see specific section
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
services: { string: string | container } # container resources to run as a service container
uses: # Any resources (repos or pools) required by this job that are not already referenced
repositories: [ string ] # Repository references to Azure Git repositories
pools: [ string ] # Pool names, typically when using a matrix strategy for the job
Para obtener más información sobre , vea Limitar el ámbito de autorización de trabajos usesuses Para obtener más información sobre las áreas de trabajo, incluidas las opciones de limpieza, vea el tema del área de trabajo en Trabajos.
jobs:
- job: string # name of the job (A-Z, a-z, 0-9, and underscore)
displayName: string # friendly name to display in the UI
dependsOn: string | [ string ]
condition: string
strategy:
parallel: # parallel strategy; see the following "Parallel" topic
matrix: # matrix strategy; see the following "Matrix" topic
maxParallel: number # maximum number of matrix jobs to run simultaneously
continueOnError: boolean # 'true' if future jobs should run even if this job fails; defaults to 'false'
pool: pool # see the following "Pool" schema
workspace:
clean: outputs | resources | all # what to clean up before the job runs
container: containerReference # container to run this job inside of
timeoutInMinutes: number # how long to run the job before automatically cancelling
cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
variables: # several syntaxes, see specific section
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
services: { string: string | container } # container resources to run as a service container
Para obtener más información sobre las áreas de trabajo, incluidas las opciones de limpieza, vea el tema del área de trabajo en Trabajos.
Obtenga más información sobre variables,pasos,gruposy trabajos de servidor.
Nota
Si solo tiene una fase y un trabajo, puede usar la sintaxis de un solo trabajo como una manera más corta de describir los pasos que se deben ejecutar.
Referencia de contenedor
Los trabajos admiten un contenedor.
container: string # Docker Hub image reference or resource alias
container:
image: string # container image name
options: string # arguments to pass to container at startup
endpoint: string # endpoint for a private container registry
env: { string: string } # list of environment variables to add
# you can also use any of the other supported container attributes
Estrategias
Las matrix palabras clave y especifican parallel estrategias mutuamente excluyentes para duplicar un trabajo.
Matriz
El uso de una matriz genera copias de un trabajo, cada uno con una entrada diferente. Estas copias son útiles para realizar pruebas con diferentes configuraciones o versiones de plataforma.
strategy:
matrix: { string1: { string2: string3 } }
maxParallel: number
Para cada aparición de string1 en la matriz, se genera una copia del trabajo. El nombre string1 es el nombre de la copia y se anexa al nombre del trabajo. Para cada aparición de string2, una variable denominada string2 con el valor string3 está disponible para el trabajo.
Nota
Los nombres de configuración de matriz solo deben contener letras alfabéticas latín básicas (A-Z y a-z), dígitos (0-9) y caracteres de subrayado ( _ ).
Deben comenzar con una letra.
Además, su longitud debe tener 100 caracteres o menos.
La palabra maxParallel clave opcional especifica el número máximo de matrices simultáneas que se ejecutarán a la vez.
Si maxParallel no se especifica o se establece en 0, no se aplica ningún límite.
Si maxParallel no se especifica, no se aplica ningún límite.
Nota
La matrix sintaxis no admite el escalado automático de trabajos, pero puede implementar una funcionalidad similar mediante la palabra each clave . Para obtener un ejemplo, vea expresiones.
Paralelo
Esta estrategia especifica cuántos duplicados de un trabajo se deben ejecutar. Resulta útil para la selección de una matriz de prueba grande. La Visual Studio prueba de pruebas entiende cómo dividir la carga de pruebas entre el número de trabajos programados.
Trabajo de implementación
Un trabajo de implementación es un tipo especial de trabajo. Se trata de una colección de pasos para ejecutarse secuencialmente en el entorno. En las canalizaciones de YAML, se recomienda colocar los pasos de implementación en un trabajo de implementación.
jobs:
- deployment: string # name of the deployment job, A-Z, a-z, 0-9, and underscore. The word "deploy" is a keyword and is unsupported as the deployment name.
displayName: string # friendly name to display in the UI
pool: # see pool schema
name: string # Use only global level variables for defining a pool name. Stage/job level variables are not supported to define pool name.
demands: string | [ string ]
workspace:
clean: outputs | resources | all # what to clean up before the job runs
dependsOn: string
condition: string
continueOnError: boolean # 'true' if future jobs should run even if this job fails; defaults to 'false'
container: containerReference # container to run this job inside
services: { string: string | container } # container resources to run as a service container
timeoutInMinutes: nonEmptyString # how long to run the job before automatically cancelling
cancelTimeoutInMinutes: nonEmptyString # how much time to give 'run always even if cancelled tasks' before killing them
variables: # several syntaxes, see specific section
environment: string # target environment name and optionally a resource name to record the deployment history; format: <environment-name>.<resource-name>
strategy:
runOnce: #rolling, canary are the other strategies that are supported
deploy:
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
Pasos
Un paso es una secuencia lineal de operaciones que forma un trabajo. Cada paso se ejecuta en su propio proceso en un agente y tiene acceso al área de trabajo de canalización en un disco duro local. Este comportamiento significa que las variables de entorno no se conservan entre pasos, pero sí los cambios del sistema de archivos.
Para obtener más información sobre los pasos, vea las referencias de esquema para:
Todos los pasos, independientemente de si están documentados en este artículo, admiten las siguientes propiedades:
- displayName
- name
- condition
- continueOnError
- enabled
- Env
- timeoutInMinutes
Variables
Puede agregar valores codificados de forma fija directamente, hacer referencia a grupos de variableso insertar mediante plantillas de variables.
Especifique variables en el nivel de canalización, fase o trabajo.
Para un conjunto simple de variables codificadas de forma fuerte, use esta sintaxis de asignación:
variables: { string: string }
Para incluir grupos de variables, cambie a esta sintaxis de secuencia:
variables:
- name: string # name of a variable
value: string # value of the variable
- group: string # name of a variable group
Puede repetir pares name/value y group .
Las variables también se pueden establecer como de solo lectura para mejorar la seguridad.
variables:
- name: myReadOnlyVar
value: myValue
readonly: true
También puede incluir variables de plantillas.
Referencias de plantilla
Nota
Asegúrese de ver la sintaxis de expresión de plantilla completa, que es todas las formas de .
Puede exportar secciones reutilizables de la canalización a un archivo independiente. Estos archivos independientes se conocen como plantillas.
Azure Pipelines admite cuatro tipos de plantillas:
También puede usar plantillas para controlar lo que se permite en una canalización y para definir cómo se pueden usar los parámetros.
Puede exportar secciones reutilizables de la canalización a archivos independientes. Estos archivos independientes se conocen como plantillas. Azure DevOps Server 2019 admite estos dos tipos de plantillas:
Las propias plantillas pueden incluir otras plantillas. Azure Pipelines admite un máximo de 50 archivos de plantilla únicos en una sola canalización.
Plantillas de fase
Puede definir un conjunto de fases en un archivo y usarlo varias veces en otros archivos.
Plantillas de trabajo
Puede definir un conjunto de trabajos en un archivo y usarlo varias veces en otros archivos.
En la canalización principal:
- template: string # name of template to include
parameters: { string: any } # provided parameters
En la plantilla incluida:
parameters: { string: any } # expected parameters
jobs: [ job ]
Consulte plantillas para obtener más información sobre cómo trabajar con plantillas de trabajo.
Plantillas de paso
Puede definir un conjunto de pasos en un archivo y usarlo varias veces en otro archivo.
En la canalización principal:
steps:
- template: string # reference to template
parameters: { string: any } # provided parameters
En la plantilla incluida:
parameters: { string: any } # expected parameters
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
Consulte plantillas para obtener más información sobre cómo trabajar con plantillas.
Plantillas de variables
Puede definir un conjunto de variables en un archivo y usarlo varias veces en otros archivos.
En la canalización principal:
- template: string # name of template file to include
parameters: { string: any } # provided parameters
En la plantilla incluida:
parameters: { string: any } # expected parameters
variables: [ variable ]
Nota
La variables palabra clave usa dos formas de sintaxis: secuencia y asignación.
En la sintaxis de asignación, todas las claves son nombres de variables y sus valores son valores de variable.
Para usar plantillas de variables, debe usar la sintaxis de secuencia.
La sintaxis de secuencia requiere que especifique si está mencionando una variable ( ), un grupo name de variables ( ) o una plantilla ( grouptemplate ).
Consulte el tema de variables para obtener más información.
Parámetros
Puede usar parámetros en plantillas y canalizaciones.
Los campos type y name son necesarios al definir parámetros. Vea todos los tipos de datos de parámetros.
parameters:
- name: string # name of the parameter; required
type: enum # see the enum data types in the following section
default: any # default value; if no default, then the parameter MUST be given by the user at runtime
values: [ string ] # allowed list of values (for some data types)
Tipos
El type valor debe ser uno de los miembros de la tabla enum siguiente.
| Tipo de datos | Notas |
|---|---|
string |
string |
number |
puede restringirse a ; de lo contrario, se acepta cualquier cadena de values: tipo número. |
boolean |
true o false |
object |
cualquier estructura YAML |
step |
un solo paso |
stepList |
secuencia de pasos |
job |
un único trabajo |
jobList |
secuencia de trabajos |
deployment |
un único trabajo de implementación |
deploymentList |
secuencia de trabajos de implementación |
stage |
una sola fase |
stageList |
secuencia de fases |
Los tipos de datos step, stepList, job, jobList, deployment, deploymentList, stage y stageList usan el formato de esquema YAML estándar. En este ejemplo se incluyen string, number, boolean, object, step y stepList.
parameters:
- name: myString
type: string
default: a string
- name: myMultiString
type: string
default: default
values:
- default
- ubuntu
- name: myNumber
type: number
default: 2
values:
- 1
- 2
- 4
- 8
- 16
- name: myBoolean
type: boolean
default: true
- name: myObject
type: object
default:
foo: FOO
bar: BAR
things:
- one
- two
- three
nested:
one: apple
two: pear
count: 3
- name: myStep
type: step
default:
script: echo my step
- name: mySteplist
type: stepList
default:
- script: echo step one
- script: echo step two
trigger: none
jobs:
- job: stepList
steps: ${{ parameters.mySteplist }}
- job: myStep
steps:
- ${{ parameters.myStep }}
Recursos
Un recurso es cualquier servicio externo que se consuma como parte de la canalización. Un ejemplo de un recurso es otra canalización de CI/CD que genera:
- Artifacts como Azure Pipelines o Jenkins.
- Repositorios de código como GitHub, Azure Repos o Git.
- Registros de imagen de contenedor como Azure Container Registry o Docker Hub.
Los recursos de YAML representan orígenes de canalizaciones, contenedores, repositorios y tipos. Para obtener más información sobre los recursos, vea aquí.
Esquema general
resources:
pipelines: [ pipeline ]
builds: [ build ]
repositories: [ repository ]
containers: [ container ]
packages: [ package ]
Recurso de canalización
Si tiene una canalización de Azure que genera artefactos, la canalización puede consumir los artefactos mediante la palabra clave pipeline para definir un recurso de canalización.
También puede habilitar desencadenadores de finalización de canalización.
resources:
pipelines:
- pipeline: string # identifier for the resource used in pipeline resource variables
project: string # project for the source; optional for current project
source: string # name of the pipeline that produces an artifact
version: string # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
branch: string # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
trigger: # triggers are not enabled by default unless you add trigger section to the resource
branches: # branch conditions to filter the events, optional; Defaults to all branches.
include: [ string ] # branches to consider the trigger events, optional; Defaults to all branches.
exclude: [ string ] # branches to discard the trigger events, optional; Defaults to none.
tags: [ string ] # list of tags to evaluate for trigger event, optional; 2020.1 and greater
stages: [ string ] # list of stages to evaluate for trigger event, optional; 2020.1 and greater
Importante
Al definir un desencadenador de recursos, si su recurso de canalización es del mismo repositorio que la canalización actual, el desencadenador sigue a la misma rama y confirma en la que se genera el evento. Pero si el recurso de canalización es de otro repositorio, la canalización actual se desencadena en la rama especificada por la rama Predeterminada para la configuración compilaciones manuales y programadas. Para obtener más información, vea Consideraciones de rama para desencadenadores de finalización de canalización.
Metadatos de recursos de canalización como variables predefinidas
En cada ejecución, los metadatos de un recurso de canalización están disponibles para todos los trabajos como estas variables predefinidas:
resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
Puede consumir artefactos de un recurso de canalización mediante una download tarea. Consulte la palabra clave download.
Recurso de contenedor
Los trabajos de contenedor permiten aislar las herramientas y dependencias dentro de un contenedor.
El agente inicia una instancia del contenedor especificado y, a continuación, ejecuta los pasos dentro de él.
La container palabra clave le permite especificar las imágenes de contenedor.
Los contenedores de servicio se ejecutan junto con un trabajo para proporcionar varias dependencias, como las bases de datos.
resources:
containers:
- container: string # identifier (A-Z, a-z, 0-9, and underscore)
image: string # container image name
options: string # arguments to pass to container at startup
endpoint: string # reference to a service connection for the private registry
env: { string: string } # list of environment variables to add
ports: [ string ] # ports to expose on the container
volumes: [ string ] # volumes to mount on the container
mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
mountReadOnly: # volumes to mount read-only - all default to false
externals: boolean # components required to talk to the agent
tasks: boolean # tasks required by the job
tools: boolean # installable tools like Python and Ruby
work: boolean # the work directory
resources:
containers:
- container: string # identifier (A-Z, a-z, 0-9, and underscore)
image: string # container image name
options: string # arguments to pass to container at startup
endpoint: string # reference to a service connection for the private registry
env: { string: string } # list of environment variables to add
ports: [ string ] # ports to expose on the container
volumes: [ string ] # volumes to mount on the container
mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
resources:
containers:
- container: string # identifier (A-Z, a-z, 0-9, and underscore)
image: string # container image name
options: string # arguments to pass to container at startup
endpoint: string # reference to a service connection for the private registry
env: { string: string } # list of environment variables to add
ports: [ string ] # ports to expose on the container
volumes: [ string ] # volumes to mount on the container
Recurso de repositorio
Si la canalización tiene plantillas en otro repositorio,debe hacer que el sistema lo sepa.
La repository palabra clave le permite especificar un repositorio externo.
Si la canalización tiene plantillas en otro repositorio osi desea usar la desprotección de varios repositorios con un repositorio que requiere una conexión de servicio, debe hacer que el sistema sepa sobre ese repositorio.
La repository palabra clave le permite especificar un repositorio externo.
resources:
repositories:
- repository: string # identifier (A-Z, a-z, 0-9, and underscore)
type: enum # see the following "Type" topic
name: string # repository name (format depends on `type`)
ref: string # ref name to use; defaults to 'refs/heads/main'
endpoint: string # name of the service connection to use (for types that aren't Azure Repos)
trigger: # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos)
branches:
include: [ string ] # branch names which will trigger a build
exclude: [ string ] # branch names which will not
tags:
include: [ string ] # tag names which will trigger a build
exclude: [ string ] # tag names which will not
paths:
include: [ string ] # file paths which must match to trigger a build
exclude: [ string ] # file paths which will not trigger a build
Tipo
Pipelines admite los siguientes valores para el tipo de repositorio: gitgithub , y bitbucket .
El git tipo hace referencia a Azure Repos repositorios de Git.
Si especifica
type: git, el valor hace referencia a otro repositorio del mismonameproyecto. Un ejemplo esname: otherRepo. Para hacer referencia a un repositorio de otro proyecto dentro de la misma organización, antefile el nombre con el nombre de ese proyecto. Un ejemplo esname: OtherProject/otherRepo.Si especifica , el valor es el nombre completo del repositorio GitHub e
type: githubincluye el usuario unameorganización. Un ejemplo esname: Microsoft/vscode. GitHub repositorios requieren una conexión GitHub servicio para la autorización.Si especifica , el valor es el nombre completo del repositorio
type: bitbucketnamede Bitbucket Cloud e incluye el usuario u organización. Un ejemplo esname: MyBitbucket/vscode. Los repositorios en la nube de Bitbucket requieren una conexión de servicio en la nube de Bitbucket para la autorización.
Recurso Paquetes
Puede consumir paquetes NuGet y npm GitHub como un recurso en canalizaciones YAML. Al especificar los recursos del paquete, establezca el paquete como NuGet o npm .
resources:
packages:
- package: myPackageAlias # alias for the package resource
type: Npm # type of the package NuGet/npm
connection: GitHubConnectionName # Github service connection with the PAT type
name: nugetTest/nodeapp # <Repository>/<Name of the package>
version: 1.0.1 # Version of the packge to consume; Optional; Defaults to latest
trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers
Desencadenadores
- Desencadenador de inserción
- Desencadenador de solicitud de extracción
- Desencadenador programado
- Desencadenador de canalización
Nota
Los bloques de desencadenador no pueden contener variables ni expresiones de plantilla.
Desencadenador de inserción
Un desencadenador de inserción especifica qué ramas hacen que se ejecute una compilación de integración continua. Si no especifica ningún desencadenador de inserción, las inserciones en cualquier rama desencadenan una compilación. Obtenga más información sobre los desencadenadores y cómo especificarlos.
Hay tres opciones de sintaxis distintas para la palabra clave: una lista de ramas que se van a incluir, una manera de deshabilitar los desencadenadores de CI y la sintaxis completa para trigger un control completo.
Sintaxis de lista:
trigger: [ string ] # list of branch names
Sintaxis de deshabilitación:
trigger: none # will disable CI builds entirely
Sintaxis completa:
trigger:
batch: boolean # batch changes if true; start a new build for every push if false (default)
branches:
include: [ string ] # branch names which will trigger a build
exclude: [ string ] # branch names which will not
tags:
include: [ string ] # tag names which will trigger a build
exclude: [ string ] # tag names which will not
paths:
include: [ string ] # file paths which must match to trigger a build
exclude: [ string ] # file paths which will not trigger a build
Si especifica una cláusula sin una cláusula para , o , es equivalente a exclude especificar en la cláusula includebranchestagspaths*include .
trigger:
batch: boolean # batch changes if true; start a new build for every push if false (default)
branches:
include: [ string ] # branch names which will trigger a build
exclude: [ string ] # branch names which will not
paths:
include: [ string ] # file paths which must match to trigger a build
exclude: [ string ] # file paths which will not trigger a build
Importante
Cuando se especifica un desencadenador, solo las ramas que se configuran explícitamente para la inclusión desencadenan una canalización. Las inclusiones se procesan primero y, a continuación, se quitan de esa lista. Si especifica una exclusión pero ninguna inclusión, no se desencadena nada.
Desencadenador de PR
Un desencadenador de solicitud de extracción especifica qué ramas hacen que se ejecute una compilación de solicitud de extracción. Si no especifica ningún desencadenador de solicitud de extracción, las solicitudes de extracción a cualquier rama desencadenan una compilación. Obtenga más información sobre los desencadenadores de solicitud de extracción y cómo especificarlos.
Importante
Los desencadenadores de PR de YAML solo se admiten GitHub y Bitbucket Cloud. Si usa git Azure Repos, puede configurar una directiva de rama para la validación de compilación para desencadenar la canalización de compilación para la validación.
Importante
Los desencadenadores de PR de YAML solo se admiten GitHub. Si usa git Azure Repos, puede configurar una directiva de rama para la validación de compilación para desencadenar la canalización de compilación para la validación.
Hay tres opciones de sintaxis distintas para la palabra clave: una lista de ramas que se van a incluir, una manera de deshabilitar los desencadenadores de PR y la sintaxis completa para pr un control completo.
Sintaxis de lista:
pr: [ string ] # list of branch names
Sintaxis de deshabilitación:
pr: none # will disable PR builds entirely; will not disable CI triggers
Sintaxis completa:
pr:
autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
branches:
include: [ string ] # branch names which will trigger a build
exclude: [ string ] # branch names which will not
paths:
include: [ string ] # file paths which must match to trigger a build
exclude: [ string ] # file paths which will not trigger a build
pr:
autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
branches:
include: [ string ] # branch names which will trigger a build
exclude: [ string ] # branch names which will not
paths:
include: [ string ] # file paths which must match to trigger a build
exclude: [ string ] # file paths which will not trigger a build
drafts: boolean # For GitHub only, whether to build draft PRs, defaults to true
Si especifica una exclude cláusula sin una cláusula para o , equivale a especificar en la cláusula includebranchespaths*include .
Importante
Cuando se especifica un desencadenador de solicitud de incorporación de extracción, solo las ramas que se configuran explícitamente para la inclusión desencadenan una canalización. Las inclusiones se procesan primero y, a continuación, se quitan de esa lista. Si especifica una exclusión pero ninguna inclusión, no se desencadena nada.
Desencadenador programado
Los desencadenadores programados de YAML no están disponibles en esta versión de Azure DevOps Server o Visual Studio Team Foundation Server. Puede usar desencadenadores programados en el editor clásico.
Un desencadenador programado especifica una programación en la que se han creado las ramas. Si no especifica ningún desencadenador programado, no se producirá ninguna compilación programada. Obtenga más información sobre los desencadenadores programados y cómo especificarlos.
schedules:
- cron: string # cron syntax defining a schedule in UTC time
displayName: string # friendly name given to a specific schedule
branches:
include: [ string ] # which branches the schedule applies to
exclude: [ string ] # which branches to exclude from the schedule
always: boolean # whether to always run the pipeline or only if there have been source code changes since the last successful scheduled run. The default is false.
Nota
Si especifica una exclude cláusula sin una cláusula para , es equivalente a especificar en la cláusula includebranches*include .
Desencadenador de canalización
Los desencadenadores de finalización de canalización se configuran mediante un recurso de canalización. Para obtener más información, vea Desencadenadores de finalización de canalización.
grupo
La pool palabra clave especifica qué grupo se pool a usar para un trabajo de la canalización.
Una pool especificación también contiene información sobre la estrategia del trabajo para ejecutarse.
En Azure DevOps Server 2019 puede especificar un grupo en el nivel de trabajo en YAML y en el nivel de canalización en la interfaz de usuario de configuración de canalización. En Azure DevOps Server 2019.1 también puede especificar un grupo en el nivel de canalización en YAML si tiene un único trabajo implícito.
Puede especificar un grupo en el nivel de canalización, fase o trabajo.
El grupo especificado en el nivel más bajo de la jerarquía se usa para ejecutar el trabajo.
La sintaxis completa es:
pool:
name: string # name of the pool to run this job in
demands: string | [ string ] # see the following "Demands" topic
vmImage: string # name of the VM image you want to use; valid only in the Microsoft-hosted pool
Si usa un grupo hospedado por Microsoft, elija una imagen de máquina virtual disponible.
Si usa un grupo privado y no necesita especificar demandas, puede acortar la sintaxis a:
pool: string # name of the private pool to run this job in
Obtenga más información sobre las condiciones y los tiempos de espera.
Peticiones
Los demands grupos privados admiten la palabra clave .
Puede comprobar la existencia de una funcionalidad o una cadena específica.
Obtenga más información sobre las demandas.
Entorno
La palabra clave especifica el entorno o su recurso que es el destino de un environment trabajo de implementación de la canalización. environment
Un entorno también contiene información sobre la estrategia de implementación para ejecutar los pasos definidos dentro del trabajo.
La sintaxis completa es:
environment: # create environment and/or record deployments
name: string # name of the environment to run this job on.
resourceName: string # name of the resource in the environment to record the deployments against
resourceId: number # resource identifier
resourceType: string # type of the resource you want to target. Supported types - virtualMachine, Kubernetes
tags: string | [ string ] # tag names to filter the resources in the environment
strategy: # deployment strategy
runOnce: # default strategy
deploy:
steps:
- script: echo Hello world
Si especifica un entorno o uno de sus recursos, pero no necesita especificar otras propiedades, puede acortar la sintaxis a:
environment: environmentName.resourceName
strategy: # deployment strategy
runOnce: # default strategy
deploy:
steps:
- script: echo Hello world
Servidor
El server valor especifica un trabajo de server.
Solo las tareas de servidor, como invocar una aplicación de función de Azure, se pueden ejecutar en un trabajo de servidor.
Cuando se usa server , un trabajo se ejecuta como un trabajo de servidor en lugar de como un trabajo de agente.
pool: server
Script
La script palabra clave es un acceso directo para la tarea de línea de script.
La tarea ejecuta un script mediante cmd.exe en Windows y Bash en otras plataformas.
steps:
- script: string # contents of the script to run
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
workingDirectory: string # initial working directory for the step
failOnStderr: boolean # if the script writes to stderr, should that be treated as the step failing?
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
timeoutInMinutes: number
env: { string: string } # list of environment variables to add
steps:
- script: string # contents of the script to run
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
workingDirectory: string # initial working directory for the step
failOnStderr: boolean # if the script writes to stderr, should that be treated as the step failing?
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
target:
container: string # where this step will run; values are the container name or the word 'host'
commands: enum # whether to process all logging commands from this step; values are `any` (default) or `restricted`
timeoutInMinutes: number
env: { string: string } # list of environment variables to add
Si no especifica un modo de comando, puede acortar la target estructura a:
- script:
target: string # container name or the word 'host'
Obtenga más información sobre las condiciones y los tiempos de espera.
Obtenga más información sobre las condiciones,los tiempos de espera,los destinos de pasoy las opciones de control de tareas para todas las tareas.
Bash
La bash palabra clave es un acceso directo para la tarea de script de bash.
La tarea ejecuta un script en Bash en Windows, macOS y Linux.
steps:
- bash: string # contents of the script to run
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
workingDirectory: string # initial working directory for the step
failOnStderr: boolean # if the script writes to stderr, should that be treated as the step failing?
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
timeoutInMinutes: number
env: { string: string } # list of environment variables to add
steps:
- bash: string # contents of the script to run
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
workingDirectory: string # initial working directory for the step
failOnStderr: boolean # if the script writes to stderr, should that be treated as the step failing?
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
target:
container: string # where this step will run; values are the container name or the word 'host'
commands: enum # whether to process all logging commands from this step; values are `any` (default) or `restricted`
timeoutInMinutes: number
env: { string: string } # list of environment variables to add
Si no especifica un modo de comando, puede acortar la target estructura a:
- bash:
target: string # container name or the word 'host'
Obtenga más información sobre las condiciones y los tiempos de espera.
Obtenga más información sobre las condiciones,los tiempos de espera,los destinos de pasoy las opciones de control de tareas para todas las tareas.
pwsh
La pwsh palabra clave es un acceso directo para la tarea de pwsh cuando el valor pwsh de esa tarea se establece en true.
La tarea ejecuta un script en PowerShell Core en Windows, macOS y Linux.
steps:
- pwsh: string # contents of the script to run
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
errorActionPreference: enum # see the following "Output stream action preferences" topic
warningPreference: enum # see the following "Output stream action preferences" topic
informationPreference: enum # see the following "Output stream action preferences" topic
verbosePreference: enum # see the following "Output stream action preferences" topic
debugPreference: enum # see the following "Output stream action preferences" topic
ignoreLASTEXITCODE: boolean # see the following "Ignore last exit code" topic
failOnStderr: boolean # if the script writes to stderr, should that be treated as the step failing?
workingDirectory: string # initial working directory for the step
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
timeoutInMinutes: number
env: { string: string } # list of environment variables to add
Nota
Cada sesión de PowerShell solo dura la duración del trabajo en el que se ejecuta. Las tareas que dependen de lo que se ha arrancado deben estar en el mismo trabajo que el arranque.
Obtenga más información sobre las condiciones y los tiempos de espera.
PowerShell
La powershell palabra clave es un acceso directo para la tarea de powershell.
La tarea ejecuta un script en Windows PowerShell.
steps:
- powershell: string # contents of the script to run
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
errorActionPreference: enum # see the following "Output stream action preferences" topic
warningPreference: enum # see the following "Output stream action preferences" topic
informationPreference: enum # see the following "Output stream action preferences" topic
verbosePreference: enum # see the following "Output stream action preferences" topic
debugPreference: enum # see the following "Output stream action preferences" topic
ignoreLASTEXITCODE: boolean # see the following "Ignore last exit code" topic
failOnStderr: boolean # if the script writes to stderr, should that be treated as the step failing?
workingDirectory: string # initial working directory for the step
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
timeoutInMinutes: number
env: { string: string } # list of environment variables to add
Nota
Cada sesión de PowerShell solo dura la duración del trabajo en el que se ejecuta. Las tareas que dependen de lo que se ha arrancado deben estar en el mismo trabajo que el arranque.
Obtenga más información sobre las condiciones y los tiempos de espera.
Preferencias de acción de flujo de salida
PowerShell proporciona varios flujos de salida que se pueden usar para registrar distintos tipos de mensajes. Los flujos error, advertencia, información, detallado y depuración transmiten toda la información que es útil en un entorno automatizado, como un trabajo del agente. PowerShell permite a los usuarios asignar una acción a cada secuencia cada vez que se escribe un mensaje en ella. Por ejemplo, si a Error la secuencia se le asignó la acción, PowerShell detendrá la ejecución Stop cada vez que se llame al Write-Error cmdlet.
La tarea de PowerShell permite invalidar la acción predeterminada de PowerShell para cada uno de estos flujos de salida cuando se ejecuta el script. Para ello, antepone una línea a la parte superior del script que establece la variable de preferencia correspondiente de la secuencia en la acción de su elección. En la tabla siguiente se enumeran las acciones admitidas por la tarea de PowerShell y lo que ocurre cuando se escribe un mensaje en la secuencia:
| Acción | Descripción |
|---|---|
| Default | Use la acción predeterminadade PowerShell . |
| Stop | Imprime el mensaje en los registros de tareas, finaliza la tarea y lo marca como con errores. |
| Continuar | Imprime el mensaje en los registros de tareas. |
| SilentlyContinue | Omite el mensaje. |
En la tabla siguiente se enumeran los flujos de salida admitidos por la tarea de PowerShell y sus acciones predeterminadas:
| STREAM | Acción predeterminada |
|---|---|
| Error | Stop |
| Advertencia | Predeterminado |
| Información | Predeterminado |
| Detallado | Predeterminado |
| Depurar | Predeterminado |
* No se admite en PowerShell 3.0.
errorActionPreference: default | stop | continue | silentlyContinue
warningPreference: default | stop | continue | silentlyContinue
informationPreference: default | stop | continue | silentlyContinue
verbosePreference: default | stop | continue | silentlyContinue
debugPreference: default | stop | continue | silentlyContinue
Omitir el último código de salida
El último código de salida devuelto desde el script está activado de forma predeterminada. Un código distinto de cero indica un error de paso, en cuyo caso el sistema anexa el script con:
if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }
Si no desea este comportamiento, especifique ignoreLASTEXITCODE: true .
Obtenga más información sobre las condiciones y los tiempos de espera.
Publicar
La publish palabra clave es un acceso directo para la tarea Publicar artefacto de publish.
La tarea publica (carga) un archivo o carpeta como un artefacto de canalización que pueden consumir otros trabajos y canalizaciones.
steps:
- publish: string # path to a file or folder
artifact: string # artifact name
displayName: string # friendly name to display in the UI
Obtenga más información sobre la publicación de artefactos.
Descargar
La download palabra clave es un acceso directo para la tarea Descargar artefacto de download.
La tarea descarga artefactos asociados a la ejecución actual o desde otra canalización de Azure asociada como un recurso de canalización.
steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
patterns: string # patterns representing files to include; optional
displayName: string # friendly name to display in the UI
Ubicación de descarga de artefactos
Artifacts de la canalización actual se descargan en $(**Pipeline.Workspace**)/<artifact name> .
Artifacts del recurso de canalización asociado se descargan en $(**Pipeline.Workspace**)/\<pipeline resource identifier\>/<artifact name> .
Descarga automática en trabajos de implementación
Todos los artefactos disponibles de la canalización actual y de los recursos de canalización asociados se descargan automáticamente en los trabajos de implementación y están disponibles para la implementación.
Para evitar descargas, especifique download: none .
Obtenga más información sobre la descarga de artefactos.
Restauración
Los trabajos que no son de implementación des check-out del código fuente automáticamente.
Use la checkout palabra clave para configurar o suprimir este comportamiento.
steps:
- checkout: self # self represents the repo where the initial Pipelines YAML file was found
clean: boolean # if true, execute `execute git clean -ffdx && git reset --hard HEAD` before fetching
fetchDepth: number # the depth of commits to ask Git to fetch (applies to submodules too if they're enabled); defaults to no limit
lfs: boolean # whether to download Git-LFS files; defaults to false
submodules: true | recursive # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
path: string # path to check out source code, relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
persistCredentials: boolean # if 'true', leave the OAuth token in the Git config after the initial fetch; defaults to false
steps:
- checkout: self | none | repository name # self represents the repo where the initial Pipelines YAML file was found
clean: boolean # if true, run `execute git clean -ffdx && git reset --hard HEAD` before fetching
fetchDepth: number # the depth of commits to ask Git to fetch; defaults to no limit
lfs: boolean # whether to download Git-LFS files; defaults to false
submodules: true | recursive # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
path: string # path to check out source code, relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
persistCredentials: boolean # if 'true', leave the OAuth token in the Git config after the initial fetch; defaults to false
Nota
Además de la opción de limpieza disponible mediante checkout , también puede configurar la limpieza en un área de trabajo. Para obtener más información sobre las áreas de trabajo, incluidas las opciones de limpieza, vea el tema del área de trabajo en Trabajos.
Para evitar la sincronización de orígenes:
steps:
- checkout: none
Nota
Si ejecuta el agente en la cuenta de servicio local y desea modificar el repositorio actual mediante operaciones de Git o cargando submódulos de Git, dele los permisos adecuados al usuario de cuentas de servicio de compilación de Project Collection.
- checkout: self
submodules: true
persistCredentials: true
Para consultar varios repositorios en la canalización, siga varios checkout pasos:
- checkout: self
- checkout: git://MyProject/MyRepo
- checkout: MyGitHubRepo # Repo declared in a repository resource
Para obtener más información, consulte Des check out multiple repositories in your pipeline.
Tarea
Las tareas son los bloques de creación de una canalización. Hay un catálogo de tareas disponibles para elegir.
steps:
- task: string # reference to a task and version, e.g. "VSBuild@1"
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
timeoutInMinutes: number
inputs: { string: string } # task-specific inputs
env: { string: string } # list of environment variables to add
steps:
- task: string # reference to a task and version, e.g. "VSBuild@1"
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
target:
container: string # where this step will run; values are the container name or the word 'host'
commands: enum # whether to process all logging commands from this step; values are `any` (default) or `restricted`
settableVariables: string # what variables are allowed; defaults to all; can be `none` or a list of allowed vars
timeoutInMinutes: number
inputs: { string: string } # task-specific inputs
env: { string: string } # list of environment variables to add
Si no especifica un modo de comando, puede acortar la target estructura a:
- task:
target: string # container name or the word 'host'
steps:
- task: string # reference to a task and version, e.g. "VSBuild@1"
displayName: string # friendly name displayed in the UI
name: string # identifier for this step (A-Z, a-z, 0-9, and underscore)
condition: string
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether to run this step; defaults to 'true'
retryCountOnTaskFailure: number # Max number of retries; default is zero
target:
container: string # where this step will run; values are the container name or the word 'host'
commands: enum # whether to process all logging commands from this step; values are `any` (default) or `restricted`
settableVariables: string # what variables are allowed; defaults to all; can be `none` or a list of allowed vars
timeoutInMinutes: number
inputs: { string: string } # task-specific inputs
env: { string: string } # list of environment variables to add
Si no especifica un modo de comando, puede acortar la target estructura a:
- task:
target: string # container name or the word 'host'
Obtenga más información sobre las condiciones,los tiempos de esperay las opciones de control de tareas para todas las tareas.
Obtenga más información sobre las condiciones,los tiempos de espera,los destinos de pasoy las opciones de control de tareas para todas las tareas.
Resalte de sintaxis
El resaltado de sintaxis está disponible para el esquema de canalización a través de Visual Studio Code extensión. Puede descargar Visual Studio Code, instalar la extensióny consultar el proyecto en GitHub. La extensión incluye un esquema JSON para la validación.
También puede obtener un esquema específico de su organización (es decir, contiene tareas personalizadas instaladas) desde el punto de conexión de yamlschemade la API REST de Azure DevOps .