Publier et télécharger des artefacts de pipeline

  • Article

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 :

Notes

La publication d’artefacts de pipeline n’est pas prise en charge dans les pipelines de mise en production.

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

Notes

Le mot clé publish est un raccourci pour la tâche Publier l’artefact de pipeline.

Bien que le nom de l’artefact soit facultatif, il est recommandé de spécifier un nom qui reflète précisément 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. La réexécution des travaux ayant échoué échoue si le package a été publié. 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

Notes

Vous ne serez pas facturé pour le stockage des artefacts de pipeline. La mise en cache du pipeline est également exemptée de la facturation de stockage. Consultez Quels artefacts comptent pour mon stockage total facturé.

Attention

La suppression d’une exécution de pipeline entraîne la suppression de tous les artefacts associés à cette exécution.

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.

Notes

Le signe plus + n’est pas pris en charge dans les chemins d’URL et certaines métadonnées de build pour les types de package tels que Maven.

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

**/*
!*.exe

Important

Azure Artifacts ignore automatiquement le chemin d’accès du dossier .git lorsque vous n’avez pas de fichier .artifactignore. Vous pouvez contourner ce problème en créant un fichier .artifactignore vide.

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
  • current : téléchargez les artefacts produits par l’exécution de pipeline en cours. Options : actuelle, spécifique.

Notes

La liste des artefacts publiés sera disponible uniquement dans les travaux dépendants suivants. Par conséquent, utilisez l’option current uniquement dans des travaux distincts, qui dépendent des travaux avec des tâches de publication d’artefacts.

Conseil

Vous pouvez utiliser des ressources de pipeline pour définir votre source en un seul endroit et l’utiliser n’importe où dans votre pipeline.

Remarque

Le download mot clé télécharge les artefacts. Pour plus d’informations, consultez steps.download.

Pour télécharger un artefact de pipeline à partir d’un autre projet dans votre organisation, assurez-vous que les autorisations appropriées sont configurées à la fois pour votre projet en aval et votre pipeline en aval. 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 est 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 échoue.

  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'

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'

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'

Screenshot showing the PowerShell task output

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.

FAQ

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.