Publier et télécharger des artefacts de pipeline

Azure DevOps Services

À l’aide d’Azure Pipelines, vous pouvez télécharger des artefacts à partir d’index antérieurs de votre pipeline ou d’un autre pipeline. Vous pouvez également publier votre artefact sur un partage de fichiers ou le rendre disponible en tant qu’artefact de pipeline.

Publier des artefacts

Vous pouvez publier vos artefacts à l’aide de YAML, de l’éditeur classique ou d’Azure CLI :

steps:
- publish: $(System.DefaultWorkingDirectory)/bin/WebApp
  artifact: WebApp

steps:
- task: PublishPipelineArtifact@1
  inputs:
    targetPath: $(System.DefaultWorkingDirectory)/bin/WebApp
    artifactName: WebApp

Bien que le nom de l'artefact soit facultatif, il est conseillé de spécifier un nom qui reflète correctement le contenu de votre artefact. Si vous envisagez de consommer l’artefact à partir d’un travail exécuté sur un autre système d’exploitation, vous devez vous assurer que tous les chemins d’accès aux fichiers sont valides pour l’environnement cible. Par exemple, un nom de fichier contenant le caractère \ ou * ne sera pas téléchargé sur Windows.

Le chemin d’accès du fichier/dossier que vous souhaitez publier est obligatoire. Il peut s’agir d’un chemin d’accès absolu ou relatif vers $(System.DefaultWorkingDirectory).

Les packages dans Azure Artifacts sont immuables. Une fois que vous avez publié un package, sa version est définitivement réservée. Si le package a été publié, la ré-exécution des tâches qui ont échoué échouera. Si vous souhaitez pouvoir réexécuter des travaux ayant échoué sans faire face à une erreur Le package existe déjà, il est judicieux d’utiliser Conditions pour effectuer l’exécution uniquement si le travail précédent a réussi.

  jobs:
  - job: Job1
    steps:
      - script: echo Hello Job1!

  - job: Job2
    steps:
      - script: echo Hello Job2!
    dependsOn: Job1

Utiliser .artifactignore

.artifactignore utilise une syntaxe similaire à .gitignore (avec quelques limitations) pour spécifier les fichiers qui doivent être ignorés lors de la publication d’artefacts. Vérifiez que le fichier .artifactignore se trouve dans le répertoire spécifié par l’argument targetPath de votre tâche Publier des artefacts de pipeline.

Exemple : ignorer tous les fichiers à l’exception des fichiers .exe :

**/*
!*.exe

Télécharger des artefacts

Vous pouvez télécharger des artefacts à l’aide de YAML, de l’éditeur classique ou d’Azure CLI.

steps:
- download: current
  artifact: WebApp

steps:
- task: DownloadPipelineArtifact@2
  inputs:
    artifact: WebApp

Pour télécharger un artefact de pipeline à partir d’un autre projet au sein de votre organisation, vérifiez que vous disposez des autorisations appropriées configurées pour le projet en aval et le pipeline générant l’artefact. Par défaut, les fichiers sont téléchargés sur $(Pipeline.Workspace). Si aucun nom d'artefact n'a été spécifié, un sous-répertoire sera créé pour chaque artefact téléchargé. Vous pouvez utiliser des modèles correspondants pour limiter le nombre de fichiers téléchargés. Pour plus d’informations, consultez Modèles de correspondance de fichiers.

steps:
- download: current
  artifact: WebApp
  patterns: |
    **/*.js
    **/*.zip

Sélection d’artefacts

Une seule étape de téléchargement peut télécharger un ou plusieurs artefacts. Pour télécharger plusieurs artefacts, laissez le champ nom de l’artefact vide et utilisez des modèles de correspondance de fichier pour limiter le nombre de fichiers à télécharger. ** est le modèle de correspondance de fichier par défaut (tous les fichiers de tous les artefacts).

Artefact unique

Quand un nom d’artefact est spécifié :

1. Seuls les fichiers de cet artefact spécifique sont téléchargés. Si l'artefact n'existe pas, la tâche échouera.

2. Les modèles de correspondance de fichier sont évalués par rapport à la racine de l’artefact. Par exemple, le modèle *.jar fait correspondre tous les fichiers avec une extension .jar à la racine de l’artefact.

L’exemple suivant illustre comment télécharger tous les *.js à partir d’un artefact WebApp :

steps:
- download: current
  artifact: WebApp
  patterns: '**/*.js'

steps:
- task: DownloadPipelineArtifact@2
  inputs:
    artifact: WebApp
    patterns: '**/*.js'
    path: $(Build.SourcesDirectory)/bin

Artefacts multiples

Quand aucun nom d’artefact n’est spécifié :

1. Plusieurs artefacts peuvent être téléchargés et la tâche n’échoue pas si aucun fichier n’est trouvé.

2. Un sous-répertoire est créé pour chaque artefact.

3. Les modèles de correspondance de fichier doivent supposer que le premier segment du modèle est (ou correspond à) un nom d’artefact. Par exemple, WebApp/** correspond à tous les fichiers de l’artefact WebApp. Le modèle */*.dll fait correspondre tous les fichiers avec une extension .dll à la racine de chaque artefact.

L’exemple suivant illustre comment télécharger tous les fichiers .zip à partir de tous les artefacts :

steps:
- download: current
  patterns: '**/*.zip'

steps:
- task: DownloadPipelineArtifact@2
  inputs:
    patterns: '**/*.zip'

Télécharger un artefact spécifique

L’exemple suivant montre comment télécharger des artefacts de pipeline à partir d’une version de build spécifique produite par une exécution particulière :

resources:
  pipelines:
  - pipeline: myPipeline
    project: 'xxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx'
    source: '79'
    version: '597'

steps:
- download: myPipeline
  artifact: drop
  patterns: '**'
  displayName: 'Download Pipeline Artifact'

steps:
- task: DownloadPipelineArtifact@2
  displayName: 'Download Pipeline Artifact'
  inputs:
    buildType: specific
    project: 'xxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx'
    definition: 79
    buildVersionToDownload: specific
    pipelineId: 597
    artifactName: drop

Artefacts dans les travaux de mise en production et de déploiement

Les artefacts sont téléchargés automatiquement uniquement dans les travaux de déploiement. Par défaut, les artefacts sont téléchargés dans $(Pipeline.Workspace). La tâche de téléchargement de l’artefact est injectée automatiquement uniquement lors de l’utilisation du hook de cycle de vie deploy dans votre déploiement. Pour empêcher le téléchargement automatique des artefacts, ajoutez une étape download et définissez sa valeur sur none. Dans une tâche de build standard, vous devez utiliser explicitement le mot clé d’étape download ou la tâche Télécharger l’artefact de pipeline. Pour en savoir plus sur les autres types de hooks, consultez Hooks de cycle de vie.

steps:
- download: none

Utiliser des artefacts dans différents index

Si vous souhaitez pouvoir accéder à votre artefact à différentes étapes de votre pipeline, vous pouvez désormais publier votre artefact en une étape, puis le télécharger à l’étape suivante en tirant parti des dépendances. Pour plus d’informations, consultez la section Dépendances de travail à travail au sein d’une étape.

Exemple

Dans l’exemple suivant, nous allons copier et publier un dossier de script de notre référentiel dans le $(Build.ArtifactStagingDirectory). Dans le deuxième index, nous allons télécharger et exécuter notre script.

trigger:
- main
stages:
- stage: build
  jobs:
  - job: run_build
    pool:
      vmImage: 'windows-latest'
    steps:
    - task: VSBuild@1
      inputs:
        solution: '**/*.sln'
        msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
        platform: 'Any CPU'
        configuration: 'Release'

    - task: CopyFiles@2
      displayName: 'Copy scripts'
      inputs:
        contents: 'scripts/**'
        targetFolder: '$(Build.ArtifactStagingDirectory)'

    - publish: '$(Build.ArtifactStagingDirectory)/scripts'
      displayName: 'Publish script'
      artifact: drop

- stage: test
  dependsOn: build
  jobs:
  - job: run_test
    pool:
      vmImage: 'windows-latest'
    steps:
    - download: current
      artifact: drop
    - task: PowerShell@2
      inputs:
        filePath: '$(Pipeline.Workspace)\drop\test.ps1'

Effectuer une migration à partir d’artefacts de build

Les artefacts de pipeline constituent la nouvelle génération d’artefacts de build et sont la méthode recommandée pour travailler avec les artefacts. Les artefacts publiés à l’aide de la tâche Publier les artefacts de build peuvent toujours être téléchargés à l’aide de Télécharger les artefacts de build, mais nous vous recommandons d’utiliser la dernière tâche Télécharger l’artefact de pipeline à la place.

Lors de la migration d’artefacts de build vers des artefacts de pipeline :

1. Par défaut, la tâche Télécharger l’artefact de pipeline télécharge les fichiers dans $(Pipeline.Workspace). Il s’agit du chemin d’accès par défaut et recommandé pour tous les types d’artefacts.

2. Les modèles de correspondance de fichier pour la tâche Télécharger les artefacts de build doivent commencer par le (ou correspondre au) nom de l’artefact, qu’un artefact spécifique ait été spécifié ou non. Dans la tâche Télécharger l’artefact de pipeline, les modèles ne doivent pas inclure le nom de l’artefact lorsqu’un nom d’artefact a déjà été spécifié. Pour plus d’informations, consultez Sélection d’artefact unique.

Exemple

- task: PublishPipelineArtifact@1
  displayName: 'Publish pipeline artifact'
  inputs:
    targetPath: '$(Pipeline.Workspace)'
    ${{ if eq(variables['Build.SourceBranchName'], 'main') }}:
        artifact: 'prod'
    ${{ else }}:
        artifact: 'dev'
    publishLocation: 'pipeline'

• targetPath : (Obligatoire) chemin d’accès du fichier ou du répertoire à publier. Peut être absolu ou relatif au répertoire de travail par défaut. Peut inclure des variables, mais les caractères génériques ne sont pas pris en charge. Par défaut : $(Pipeline.Workspace).

• publishLocation : (Obligatoire) emplacement de publication des artefacts. Choisissez entre le stockage de l'artefact dans Azure Pipelines, ou sa copie sur un partage de fichiers accessible à partir de l'agent de pipeline. Options : pipeline, filepath. Par défaut : pipeline.

• artifact : (Facultatif) nom de l’artefact à publier. S’il n’est pas défini, la valeur par défaut est un ID unique délimité au travail.

Afficher les artefacts publiés

Une fois l'exécution de votre pipeline terminée, procédez comme suit pour afficher ou télécharger votre artefact publié :

1. Connectez-vous à votre organisation Azure DevOps puis accédez à votre projet.

2. Sélectionnez Pipelines, sélectionnez votre pipeline, puis l'onglet Résumé.

3. Dans la section connexe, sélectionnez l'artefact publié.

   

4. Développez le dossier de dépôt pour localiser votre artefact. Vous pouvez alors télécharger votre artefact et explorer son contenu.

   

Forum aux questions

Q : Que sont les artefacts de build ?

R : Les artefacts de build sont les fichiers générés par votre build. Consultez Générer des artefacts pour en savoir plus sur la publication et la consommation de vos artefacts de build.

Q : Puis-je supprimer des artefacts de pipeline en cas de réexécution de travaux ayant échoué ?

R : Les artefacts de pipeline ne peuvent pas être supprimés ni remplacés. Si vous souhaitez régénérer des artefacts lorsque vous réexécutez un travail ayant échoué, vous pouvez inclure l’ID du travail dans le nom de l’artefact. $(system.JobId) est la variable appropriée à cet effet. Consultez Variables système pour en savoir plus sur les variables prédéfinies.

Q : Comment puis-je accéder aux flux d’artefacts derrière un pare-feu ?

R : Si votre organisation utilise un pare-feu ou un serveur proxy, veillez à autoriser les URL et adresses IP du domaine Azure Artifacts.

Articles connexes

• Artefacts de build
• Mises en production dans Azure Pipelines
• Artefacts de mise en production et sources d’artefact
• Comment atténuer les risques lors de l’utilisation de flux de packages privés