Partager via


Spécifier des travaux dans votre pipeline

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

Vous pouvez organiser votre pipeline en travaux. Chaque pipeline comprend au moins un travail. Un travail consiste en une série d’étapes qui s’exécutent de manière séquentielle comme un tout. En d’autres termes, il s’agit de la plus petite unité de travail dont on puisse planifier l’exécution.

Pour en savoir plus sur les concepts et composants clés qui composent un pipeline, consultez Les concepts clés pour les nouveaux utilisateurs d’Azure Pipelines.

Azure Pipelines ne prend pas en charge la priorité des travaux pour les pipelines YAML. Pour contrôler quand les travaux s’exécutent, vous pouvez spécifier des conditions et des dépendances.

Définition d’un seul travail

Dans le cas le plus simple, un pipeline comporte un seul travail. Il n’est alors pas nécessaire d’utiliser explicitement le mot clé job, à moins de recourir à un modèle. Vous pouvez spécifier directement les étapes dans votre fichier YAML.

Ce fichier YAML comprend un travail qui s’exécute sur un agent hébergé par Microsoft et génère Hello world.

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

Vous pouvez spécifier d’autres propriétés sur ce travail. Dans ce cas, utilisez le mot clé job.

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

Votre pipeline peut comporter plusieurs travaux. Dans ce cas, utilisez le mot clé jobs.

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Votre pipeline peut comprendre plusieurs phases, chacune décomposée en plusieurs travaux. Dans ce cas, utilisez le mot clé stages.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

La syntaxe complète pour spécifier un travail est la suivante :

- 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
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  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: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container

La syntaxe complète pour spécifier un travail est la suivante :

- 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
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  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: { string: string } | [ variable | variableReference ] 
  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

Si l’objectif principal de votre travail consiste à déployer votre application (par opposition à générer ou tester votre application), vous pouvez utiliser un type de travail spécial appelé travail de déploiement.

La syntaxe d’un travail de déploiement est la suivante :

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

Bien qu’il soit possible d’ajouter des étapes de tâches de déploiement dans un job, nous vous recommandons d’utiliser plutôt un travail de déploiement. Un travail de déploiement présente quelques avantages. Par exemple, vous pouvez effectuer un déploiement dans un environnement, ce qui permet notamment de voir l’historique de ce que vous avez déployé.

Types de travaux

Les travaux peuvent être de différents types selon l’endroit où ils s’exécutent.

  • Les travaux de pool d’agents s’exécutent sur un agent dans un pool d’agents.
  • Les travaux de serveur s’exécutent sur Azure DevOps Server.
  • Les travaux de conteneur s’exécutent dans un conteneur sur un agent dans un pool d’agents. Pour plus d’informations sur le choix des conteneurs, consultez Définition de travaux de conteneur.
  • Les travaux de pool d’agents s’exécutent sur un agent dans un pool d’agents.
  • Les travaux de serveur s’exécutent sur Azure DevOps Server.

Travaux de pool d’agents

Il s’agit du type de travail le plus courant. Il s’exécute sur un agent dans un pool d’agents.

  • Lorsque vous utilisez des agents hébergés par Microsoft, chaque travail d’un pipeline obtient un nouvel agent.
  • Utilisez des demandes avec des agents autohébergés afin de spécifier les fonctionnalités qu’un agent doit posséder pour exécuter votre travail. Il peut arriver que vous obteniez le même agent pour des travaux consécutifs, selon qu’il existe dans votre pool d’agents plusieurs agents qui répondent aux demandes de votre pipeline. Si votre pool ne comprend qu’un seul agent adapté, le pipeline attend que ce dernier soit disponible.

Remarque

Les demandes et les fonctionnalités sont conçues pour être utilisées avec des agents autohébergés afin que les travaux puissent être mis en correspondance avec un agent qui répond à leurs demandes. Si vous avez recours à des agents hébergés par Microsoft, vous sélectionnez pour l’agent une image adaptée aux exigences du travail. Par conséquent, les fonctionnalités ne sont pas nécessaires avec ce type d’agent, bien qu’il soit possible de lui en ajouter.

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

Le code se présente ainsi dans le cas de demandes multiples :

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

Découvrez les fonctionnalités de l’agent.

Travaux de serveur

Les tâches d’un travail de serveur sont orchestrées par et exécutées sur le serveur (Azure Pipelines ou TFS). Un travail de serveur ne nécessite pas d’agent ni d’ordinateurs cibles. Seules quelques tâches sont actuellement prises en charge dans un travail de serveur. La durée maximale d’un travail de serveur est de 30 jours.

Tâches prises en charge par les travaux sans agent

Actuellement, seules les tâches suivantes sont prises en charge d’emblée pour les travaux sans agent :

Étant donné que les tâches sont extensibles, vous pouvez en ajouter d’autres sans agent à l’aide d’extensions. Le délai d’expiration par défaut des travaux sans agent est de 60 minutes.

La syntaxe complète pour spécifier un travail de serveur est la suivante :

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Vous pouvez également utiliser la syntaxe simplifiée :

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Les dépendances

Lorsque vous définissez plusieurs travaux dans une seule phase, vous pouvez spécifier des dépendances entre eux. Les pipelines doivent contenir au moins un travail sans dépendance. Par défaut, les travaux de pipeline YAML Azure DevOps s’exécutent en parallèle, à moins que la valeur dependsOn ne soit définie.

Remarque

Un agent ne peut exécuter qu’un seul travail à la fois. Pour exécuter plusieurs travaux en parallèle, vous devez configurer plusieurs agents. Il vous faut également un nombre suffisant de travaux parallèles.

La syntaxe pour définir plusieurs travaux et leurs dépendances est la suivante :

jobs:
- job: string
  dependsOn: string
  condition: string

Voici quelques exemples de travaux générés séquentiellement :

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

Voici quelques exemples de travaux générés en parallèle (sans dépendance) :

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

Voici un exemple de distribution ramifiée :

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

Exemple de distribution non ramifiée :

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

Conditions

Vous pouvez spécifier les conditions d’exécution de chaque travail. Par défaut, un travail s’exécute à condition de ne dépendre d’aucun autre travail, ou que tous les travaux dont il dépend soient terminés et réussis. Vous pouvez personnaliser ce comportement en forçant l’exécution d’un travail en cas d’échec d’un travail précédent ou en spécifiant une condition personnalisée.

Voici un exemple d’exécution d’un travail en fonction de l’état de l’exécution d’un travail précédent :

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

Voici un exemple d’utilisation d’une condition personnalisée :

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))
  steps:
  - script: echo this only runs for master

Vous pouvez spécifier qu’un travail s’exécute en fonction de la valeur d’une variable de sortie définie dans un travail précédent. Dans ce cas, seules les variables définies dans des travaux directement dépendants peuvent être utilisées :

jobs:
- job: A
  steps:
  - script: "echo '##vso[task.setvariable variable=skipsubsequent;isOutput=true]false'"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

Délais d'attente

Pour éviter de consommer des ressources lorsque le travail ne répond pas ou attend trop longtemps, il est judicieux de limiter la durée pendant laquelle le travail est autorisé à s’exécuter. Utilisez le paramètre de délai d’expiration du travail pour spécifier la limite d’exécution du travail en minutes. La valeur zéro signifie que le travail peut s’exécuter pendant les durées suivantes :

  • Pour toujours sur les agents autohébergés
  • Pendant 360 minutes (6 heures) sur les agents hébergés par Microsoft avec un projet public et un référentiel public
  • Pendant 60 minutes sur les agents hébergés par Microsoft avec un projet privé ou un référentiel privé (à moins de payer une capacité supplémentaire)

Le délai d’expiration commence au début de l’exécution du travail. Il n’inclut pas le temps de mise en file d’attente du travail ni le temps d’attente d’un agent.

timeoutInMinutes permet de fixer la limite du temps d’exécution du travail. Quand elle n’est pas spécifiée, la valeur par défaut est de 60 minutes. Si elle est égale à 0, la limite maximale est utilisée (cf. ci-dessus).

cancelTimeoutInMinutes permet de fixer la limite du délai d’annulation du travail lorsque la tâche de déploiement est définie de façon à continuer à s’exécuter en cas d’échec d’une tâche précédente. Quand elle n’est pas spécifiée, la valeur par défaut est de 5 minutes. La valeur doit être comprise entre 1 et 35 790 minutes.

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

Les délais d’expiration ont le niveau de précédence suivant.

  1. Sur les agents hébergés par Microsoft, les travaux sont limités dans la durée pendant laquelle ils peuvent s’exécuter en fonction du type de projet et s’ils sont exécutés à l’aide d’un travail parallèle payant. Lorsque l’intervalle de délai d’expiration du travail hébergé par Microsoft est écoulé, le travail est arrêté. Sur les agents hébergés par Microsoft, les travaux ne peuvent pas s’exécuter plus longtemps que cet intervalle, quel que soit le délai d’expiration du niveau du travail spécifié dans le travail.
  2. Le délai d’expiration configuré au niveau du travail spécifie la durée maximale de l’exécution du travail. Lorsque l’intervalle de délai d’expiration du niveau de travail est écoulé, le travail est arrêté. Si le travail est exécuté sur un agent hébergé par Microsoft, la définition du délai d’expiration au niveau du travail sur un intervalle supérieur au délai d’expiration du travail hébergé par Microsoft intégré n’a aucun effet et le délai d’expiration du travail hébergé par Microsoft est utilisé.
  3. Vous pouvez également définir le délai d’expiration de chaque tâche individuellement : consultez les options de contrôle des tâches. Si l’intervalle de délai d’expiration du niveau du travail s’écoule avant la fin de la tâche, le travail en cours d’exécution est arrêté, même si la tâche est configurée avec un intervalle de délai d’expiration plus long.

Configuration à plusieurs travaux

À partir d’un seul travail créé, vous pouvez exécuter plusieurs travaux sur différents agents en parallèle. Voici quelques exemples :

  • Builds multiconfigurations : générez plusieurs configurations en parallèle. Par exemple, vous pouvez créer une application Visual C++ pour les configurations debug et release sur les plateformes x86 et x64. Pour plus d’informations, consultez Visual Studio Build : plusieurs configurations pour plusieurs plateformes.

  • Déploiements multiconfigurations : exécutez plusieurs déploiements en parallèle, par exemple dans différentes régions géographiques.

  • Test multiconfiguration : exécutez plusieurs configurations de test en parallèle.

  • La multiconfiguration génère toujours au moins un travail, même si une variable multiconfiguration est vide.

La stratégie matrix permet de répartir un travail plusieurs fois, avec différents ensembles de variables. La balise maxParallel limite la quantité de parallélisme. Le travail suivant est réparti trois fois avec les valeurs Emplacement et Navigateur définies comme spécifié. Toutefois, seuls deux travaux s’exécutent en même temps.

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

Remarque

Le nom des configurations de matrice (par exemple US_IE ci-dessus) ne doit contenir que des lettres alphabétiques latines de base (A-Z et a-z), des chiffres et des traits de soulignement (_). Ils doivent commencer par une lettre. Il doit également comporter 100 caractères maximum.

Il est également possible d’utiliser des variables de sortie pour générer une matrice. Cette solution peut se révéler pratique si vous devez pour cela passer par un script.

matrix accepte une expression runtime contenant un objet JSON stringifié. Lorsqu’il est développé, cet objet JSON doit correspondre à la syntaxe de matrice. Dans l’exemple ci-dessous, la chaîne JSON est codée en dur, mais elle peut être générée par un langage de script ou un programme de ligne de commande.

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

Découpage

Un travail d’agent peut être utilisé pour exécuter une suite de tests en parallèle. Par exemple, vous pouvez exécuter une grande série de 1000 tests sur un seul agent. Vous pouvez également vous servir de deux agents et lancer 500 tests sur chacun d’eux en parallèle.

Il est nécessaire, pour appliquer le découpage, que les tâches du travail soient suffisamment intelligentes pour savoir à quelle tranche elles appartiennent.

La tâche de test Visual Studio est une tâche de ce type qui prend en charge le découpage des tests. Si vous avez installé plusieurs agents, vous pouvez spécifier la façon dont la tâche Visual Studio Test s’exécute en parallèle sur ces agents.

La stratégie parallel permet de dupliquer un travail plusieurs fois. Les variables System.JobPositionInPhase et System.TotalJobsInPhase sont ajoutées à chaque travail. Les variables peuvent ensuite être utilisées dans les scripts pour répartir la charge entre les travaux (cf. Exécution parallèle et multiple à l’aide de travaux d’agent).

Le travail suivant est réparti cinq fois avec les valeurs de System.JobPositionInPhase et de System.TotalJobsInPhase correctement définies.

jobs:
- job: Test
  strategy:
    parallel: 5

Variables de travail

Si vous utilisez YAML, vous avez la possibilité de spécifier des variables sur le travail. Elles peuvent être passées aux entrées de tâche suivant la syntaxe de macro $(variableName) ou récupérées dans un script à l’aide de la variable de phase.

Voici un exemple de définition de variables dans un travail et d’utilisation dans des tâches.

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

Pour plus d’informations sur l’utilisation d’une condition, consultez Spécification de conditions.

Espace de travail

Lorsqu’il s’exécute, un travail de pool d’agents crée un espace de travail sur l’agent. Cet espace de travail consiste en un répertoire dans lequel il télécharge la source, exécute les étapes et produit des sorties. Vous pouvez faire référence au répertoire de l’espace de travail dans votre travail à l’aide de la variable Pipeline.Workspace. Dans ce cadre, différents sous-répertoires sont créés :

  • Build.SourcesDirectory : l’endroit où les tâches téléchargent le code source de l’application.
  • Build.ArtifactStagingDirectory : l’endroit où les tâches téléchargent les artefacts nécessaires au pipeline ou chargent les artefacts avant leur publication.
  • Build.BinariesDirectory : l’endroit où les tâches écrivent leurs sorties.
  • Common.TestResultsDirectory : l’endroit où les tâches chargent leurs résultats de test.

$(Build.ArtifactStagingDirectory) et $(Common.TestResultsDirectory) sont toujours supprimés et recréés avant chaque build.

Lorsque vous exécutez un pipeline sur un agent autohébergé, par défaut, aucun des sous-répertoires autres que $(Build.ArtifactStagingDirectory) et $(Common.TestResultsDirectory) n’est nettoyé entre deux exécutions consécutives. Vous pouvez donc exécuter des builds et des déploiements incrémentiels, à condition que des tâches soient implémentées pour cela. Il est possible de remplacer ce comportement en utilisant le paramètre workspace sur le travail.

Important

Les options clean de l’espace de travail ne s’appliquent qu’aux agents autohébergés. Les travaux sont toujours exécutés sur un nouvel agent avec des agents hébergés par Microsoft.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Les options clean spécifiées sont interprétées comme suit :

  • outputs : supprimer le répertoire Build.BinariesDirectory avant d’exécuter un nouveau travail.
  • resources : supprimer le répertoire Build.SourcesDirectory avant d’exécuter un nouveau travail.
  • all : supprimez l’intégralité du répertoire Pipeline.Workspace avant d’exécuter un nouveau travail.
  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Notes

En fonction des fonctionnalités de votre agent et des demandes du pipeline, chaque travail peut être dirigé vers un agent différent dans le pool autohébergé. Vous pouvez donc obtenir un nouvel agent pour les exécutions de pipeline suivantes (ou les phases et travaux du même pipeline). Par conséquent, le fait de ne pas effectuer de nettoyage ne garantit pas que les exécutions, travaux et phases suivants pourront accéder aux sorties des précédents. Vous pouvez configurer les fonctionnalités de l’agent et les demandes du pipeline de façon à spécifier les agents utilisés pour exécuter un travail de pipeline. Cependant, à moins qu’il n’existe dans le pool qu’un seul agent qui réponde aux demandes, il n’y a aucune garantie que les travaux suivants utiliseront le même agent que les précédents. Pour plus d’informations, consultez Spécification des demandes.

En plus de l’option clean de l’espace de travail, vous pouvez également configurer le nettoyage en définissant le paramètre Nettoyer dans l’interface utilisateur des paramètres du pipeline. Lorsque le paramètre Nettoyer a la valeur true (qui constitue également sa valeur par défaut), il équivaut à spécifier clean: true pour chaque étape checkout du pipeline. Si vous spécifiez clean: true, vous exécutez git clean -ffdx suivi de git reset --hard HEAD avant la récupération (fetch) Git. Pour configurer le paramètre Nettoyer, procédez comme suit :

  1. Modifiez votre pipeline, choisissez , puis sélectionnez Déclencheurs.

    Modification des déclencheurs.

  2. Sélectionnez YAML et Obtenir des sources, puis configurez le paramètre Nettoyer souhaité. La valeur par défaut est true.

    Paramètre Nettoyer.

Téléchargement d’artefacts

Cet exemple de fichier YAML publie l’artefact WebSite, puis le télécharge dans $(Pipeline.Workspace). Le travail de déploiement ne s’exécute que si le travail de build réussit.

# test and upload my code as an artifact named WebSite
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishBuildArtifacts@1
    inputs:
      pathtoPublish: '$(System.DefaultWorkingDirectory)'
      artifactName: WebSite

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

Pour plus d’informations sur l’utilisation de dependsOn et de condition, consultez Spécification de conditions.

Accès au jeton OAuth

Vous pouvez autoriser les scripts exécutés dans un travail à accéder au jeton de sécurité OAuth Azure Pipelines ou TFS actuel. Le jeton peut être utilisé pour s’authentifier auprès de l’API REST Azure Pipelines.

Le jeton OAuth est toujours disponible pour les pipelines YAML. Il doit être mappé explicitement à la tâche ou à l’étape à l’aide de env. Voici un exemple :

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

Et après ?