I am looking for a task which could download a latest commit based on the tag from Azure Repos. I mean whole files/folders structures from Azure Repos which is than use to build the application. Then use it for different environments', like Test, than Integration, and Production. Now, I am a bit confused with the order/tasks/reusability:

1. The first stage which is called Build could download that package from Azure Repo and than publish? So two tasks DownloadGitHubRelease@0 and PublishPipelineArtifact@1 to publish that artifact? By the way I do not see the task which could download packages from Azure Repo, only that one DownloadGitHubRelease@0 which is designed for GitHub, am I right?
2. The second stage called Test should download that artifact with DownloadBuildArtifacts@1 (means above package), and extract it with ExtractFiles@1.
3. The same steps/tasks such as above for Production stage.

Is that correct way? Or is that any better approach? My beginning:

trigger:
  branches:
    include:
      - master/*

resources:
  repositories:
    - repository: pipeline
      type: git
      name: pipeline
      ref: auto/*
    - repository: Automotive
      type: git
      name: autoomotive
      ref: master

variables:
  - template: variables.yml
  - name: releaseTag
    value: '18.11.0'

stages:
  - stage: Build
    jobs:
      - job: DownloadPackage
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadGitHubRelease@0
            inputs:
              repository: 'OEM/Automotive'
              tags: |
                [latest]
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: PublishPipelineArtifact@1
            inputs:
              targetPath: '$(System.ArtifactsDirectory)/AutomotivePackage'
              artifactName: 'AutomotivePackage'
              publishLocation: 'pipeline'

  - stage: Test
    jobs:
      - job: TestDeployment
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              buildType: 'current'
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: ExtractFiles@1
            inputs:
              archiveFilePatterns: '$(System.ArtifactsDirectory)/AutomotivePackage/*.tar.gz'
              destinationFolder: '$(System.DefaultWorkingDirectory)/Automotive'

  - stage: Production
    jobs:
      - job: ProdDeployment
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              buildType: 'current'
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: ExtractFiles@1
            inputs:
              archiveFilePatterns: '$(System.ArtifactsDirectory)/AutomotivePackage/*.tar.gz'
              destinationFolder: '$(System.DefaultWorkingDirectory)/Automotive'

My imagination is that developer commit new package with tag, than Azure Devops takes the changes and run pipeline.

I am looking for a task which could download a latest commit based on the tag from Azure Repos. I mean whole files/folders structures from Azure Repos which is than use to build the application. Then use it for different environments', like Test, than Integration, and Production. Now, I am a bit confused with the order/tasks/reusability:

1. The first stage which is called Build could download that package from Azure Repo and than publish? So two tasks DownloadGitHubRelease@0 and PublishPipelineArtifact@1 to publish that artifact? By the way I do not see the task which could download packages from Azure Repo, only that one DownloadGitHubRelease@0 which is designed for GitHub, am I right?
2. The second stage called Test should download that artifact with DownloadBuildArtifacts@1 (means above package), and extract it with ExtractFiles@1.
3. The same steps/tasks such as above for Production stage.

Is that correct way? Or is that any better approach? My beginning:

trigger:
  branches:
    include:
      - master/*

resources:
  repositories:
    - repository: pipeline
      type: git
      name: pipeline
      ref: auto/*
    - repository: Automotive
      type: git
      name: autoomotive
      ref: master

variables:
  - template: variables.yml
  - name: releaseTag
    value: '18.11.0'

stages:
  - stage: Build
    jobs:
      - job: DownloadPackage
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadGitHubRelease@0
            inputs:
              repository: 'OEM/Automotive'
              tags: |
                [latest]
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: PublishPipelineArtifact@1
            inputs:
              targetPath: '$(System.ArtifactsDirectory)/AutomotivePackage'
              artifactName: 'AutomotivePackage'
              publishLocation: 'pipeline'

  - stage: Test
    jobs:
      - job: TestDeployment
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              buildType: 'current'
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: ExtractFiles@1
            inputs:
              archiveFilePatterns: '$(System.ArtifactsDirectory)/AutomotivePackage/*.tar.gz'
              destinationFolder: '$(System.DefaultWorkingDirectory)/Automotive'

  - stage: Production
    jobs:
      - job: ProdDeployment
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              buildType: 'current'
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: ExtractFiles@1
            inputs:
              archiveFilePatterns: '$(System.ArtifactsDirectory)/AutomotivePackage/*.tar.gz'
              destinationFolder: '$(System.DefaultWorkingDirectory)/Automotive'

My imagination is that developer commit new package with tag, than Azure Devops takes the changes and run pipeline.

• azure-devops

• Are you trying to copy artifacts from a previous build in order to deploy them? Is the deployment location a server in your Azure environment? or outside of it? – Kevin Commented Nov 18, 2024 at 20:51
• Are you trying to copy artifacts from a previous build in order to deploy them? From the latest, so pipeline should start when new tagged commit by developer is done. Did I confuse something in my example, thats why you asked about the previous one? Is the deployment location a server in your Azure environment? or outside of it? Yes, I would say everything from Microsoft I am using here, Azure, Azure Repo, and Azure DevOps. However, in this case the repository with application is in different repository than that one which manage this pipeline. – Kreg Commented Nov 18, 2024 at 21:04
• I think what you need is simpler than your question makes it sound. When you set up a pipeline, you establish the source repo, and don't need to explicitly type that into your yml. This performs the first part of your question. The pipeline then performs a build and creates artifacts. I think what you're really missing is deploying the artifacts. Does this sound correct? – Kevin Commented Nov 18, 2024 at 21:21
• I think you may be right, I treat each task too carefully when pipeline already does part of the work for me. I read about it all the time and I see that the pipeline in my repo, where I keep the pipelines, can listen for changes in the Automotive repo and based on e.g. a tag, run the pipeline while building the application. But how do I wrap it in tasks now :/ – Kreg Commented Nov 18, 2024 at 21:34
• From your example it looks like you want to deploy MASTER builds to all your environments. I have posted an example answer that will accomplish this. If you need something different, you might want to break your question down and be very specific. For example, in my own work case it was easier to make 3 different pipelines and use a template for steps shared throughout, that would do dev, staging, and prod builds and deployments based on the branch triggering the pipeline, rather than trying to make one pipeline do everything. – Kevin Commented Nov 18, 2024 at 22:24

2 Answers 2

It sounds like all you need is to add a deployment step to your existing build pipeline. This will copy the most recent build artifacts to your desired location. Since your location is in your Azure environment you'll want to look at all the deployment tasks and decide which one does exactly what you want.

for example:

-task: AzureFileCopy@4

inputs:
  sourcePath: $(Build.ArtifactStagingDirectory)/drop  
  azureSubscription: 
  resourceGroupName: 
  destinationFolder:

Is simple and straight forward. There are other deployment tasks if your need is more in depth than simple copy.

From your example pipeline, it looks like you could add a job with this task to each of your stages, and this will perform the deployment of the artifacts.

I recommend the destination folder is NOT the working directory for your websites until you are sufficiently happy with the way your deployment tasks are working.

You may also need some powershell, or other script, tasks to stop your services or websites and restart them after deployment is complete.

Based on comment and question description, the pipeline need to listen the commit tag changes in Automotive repo, then trigger pipeline and download azure repo based on related changed tag.

To meet your requirement, you can set tag trigger in repo resources and directly use - checkout: repoalias to download the azure repo based on related changed tag.

Tag trigger:

resources:
  repositories:
    - repository: Automotive
      type: git
      name: autoomotive
      ref: master
      trigger:
       tags:
        include:
          - '*'

Download Azure Repo:

- checkout: Automotive

Here is an example:

trigger:
  branches:
    include:
      - master/*

resources:
  repositories:
    - repository: pipeline
      type: git
      name: pipeline
      ref: auto/*
    - repository: Automotive
      type: git
      name: autoomotive
      ref: master
      trigger:
       tags:
        include:
          - '*'

variables:
  - template: variables.yml

stages:
  - stage: Build
    jobs:
      - job: DownloadPackage
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - checkout: Automotive
    
          - task: PublishPipelineArtifact@1
            inputs:
              targetPath: '$(System.ArtifactsDirectory)/AutomotivePackage'
              artifactName: 'AutomotivePackage'
              publishLocation: 'pipeline'

  - stage: Test
    jobs:
      - job: TestDeployment
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              buildType: 'current'
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: ExtractFiles@1
            inputs:
              archiveFilePatterns: '$(System.ArtifactsDirectory)/AutomotivePackage/*.tar.gz'
              destinationFolder: '$(System.DefaultWorkingDirectory)/Automotive'

  - stage: Production
    jobs:
      - job: ProdDeployment
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              buildType: 'current'
              artifactName: 'AutomotivePackage'
              downloadPath: '$(System.ArtifactsDirectory)'
          - task: ExtractFiles@1
            inputs:
              archiveFilePatterns: '$(System.ArtifactsDirectory)/AutomotivePackage/*.tar.gz'
              destinationFolder: '$(System.DefaultWorkingDirectory)/Automotive'

When developers commit new package with tag to azure repo, it will automatically trigger the pipeline and the checkout step will download the azure repo with the related committed tag.

If you need to download the repo which is used to create pipeline, you can add - checkout: self to check the related repo.

Here is the doc about checkout definition.

Result: