Azure-pipelines-tasks: "Download Pipeline Artifacts" is missing output variable BuildNumber

[avivanoff]

Required Information

Type: Bug

Task Name: Download Pipeline Artifacts

Environment

• Azure Pipelines

Issue Description

"Download Pipeline Artifacts" task does not have the output variable BuildNumber that makes it impossible to get the id of the build the artifact was downloaded from.

"Download build artifacts" task have this output variable.

[fadnavistanmay]

Adding @jahsu-MSFT .

Which version of download pipeline artifact task are you using. This has been fixed in version 2 .

e.g:

[jahsu-MSFT]

@avivanoff The build Id should be printed out in the logs. Where do you expect to get the build Id from?

[avivanoff]

@jahsu-MSFT, I expect it to be available as an output variable, see "Download build artifacts" task:

[avivanoff]

@jahsu-MSFT, any updates on the issue? We are planning to switch build artifacts to pipeline artifacts, and this is one of the issues that prevents us from making the switch.

[avivanoff]

@jahsu-MSFT, BuildNumber is a confusing name, as it really is a build id, not a build number. I wander if you should fix the confusion call it BuildId (or better yet PipelineId).

[jahsu-MSFT]

@avivanoff I see your point. However, the reason we'd like to keep the name as the same as the build artifact task is because, when migrating from build artifact task to pipeline artifact task, we don't want to break any users.

[avivanoff]

@jahsu-MSFT, you could add PipelineId, as well as BuildNumber output variables, and update documentation to say that BuildNumber is deprecated and PipelineId should be used instead.

[jahsu-MSFT]

@avivanoff We don't think it's necessary to create a duplicate output variable here. We can potentially consider updating the new output variable name in a newer download pipeline artifact version (for example, V3 ) but for now, our goal is to make the download pipeline artifact V2 task compatible with download build artifact.

[avivanoff]

Ok, that works.

[avivanoff]

@jahsu-MSFT, when should we expect the updated task?

[avivanoff]

@jahsu-MSFT, the task is still missing the output variable. Please re-open this bug until the changes are deployed.

[jahsu-MSFT]

@fadnavistanmay Please merge the task PR as well after ensuring this agent change is deployed to all rings.
Previously, the agent deployment had some issues, therefore; we weren't able to merge the task PR.

[avivanoff]

@jahsu-MSFT, @fadnavistanmay, any updates?

[fadnavistanmay]

@avivanoff - please expect this to be deployed in a week or so. Thanks

[floschnell]

probably makes sense to review the development/deployment process.
in my opinion, a simple addition like this shouldn't take 3 months to get deployed.

[avivanoff]

@jahsu-MSFT, @fadnavistanmay, it has been over two weeks, updates have not been deployed yet.

[fadnavistanmay]

@avivanoff - We have added this to out backlog. We can't prioritize it right now due to high priority competing work.

[avivanoff]

@fadnavistanmay, my understanding is that development is done, all you need to do is publish updated task. @jahsu-MSFT, is this correct?

[trinhpham]

@avivanoff We don't think it's necessary to create a duplicate output variable here. We can potentially consider updating the new output variable name in a newer download pipeline artifact version (for example, V3 ) but for now, our goal is to make the download pipeline artifact V2 task compatible with download build artifact.

To me, the wrong value of BuildNumber (it's set to BuildId instead) in Download Build Artifact causes me not to use it. Keeping backward compatible here seems to be valueless and need to be re-considered. Why not both: pipelineId & pipelineNumber?

[avivanoff]

@fadnavistanmay, @jahsu-MSFT, any updates?

[fadnavistanmay]

@avivanoff - the new task version will be released starting Monday. Could you ping me your org name, I can tell you when you can expect the new task. Thanks, and sorry for the delay.

[fadnavistanmay]

Hello, This is in the process of release - and should be available with DPAV2 task in few days. Please feel free to re-open if you have any issues with the new feature.

[avivanoff]

@fadnavistanmay, our instance still does not have changes. Although, because of this bug I do not think we care anymore.

[jesperll]

I'm still not seeing this in production.

According to the checkin at https://github.com/microsoft/azure-pipelines-tasks/commit/8757a01e7b32d45353983455670bba917acd4b45 this is released as version 2.3.0 on agents newer than 2.164.1

Why am I not getting it in my build then? Is your roll-out of new features really that slow?

2020-04-03T06:53:57.8918529Z ##[section]Starting: Initialize job
2020-04-03T06:53:57.8919011Z Agent name: 'Hosted Agent'
2020-04-03T06:53:57.8919298Z Agent machine name: 'fv-az100'
2020-04-03T06:53:57.8919519Z Current agent version: '2.165.2'
2020-04-03T06:53:57.8920556Z Current image version: '20200316.1'
2020-04-03T06:53:57.8924917Z Agent running as: 'vsts'
2020-04-03T06:53:57.8969305Z Prepare build directory.
2020-04-03T06:53:57.9228457Z Set build variables.
2020-04-03T06:53:57.9259324Z Download all required tasks.
2020-04-03T06:53:57.9358640Z Downloading task: DownloadPipelineArtifact (2.2.0)
2020-04-03T06:53:59.0035466Z Downloading task: CmdLine (2.164.0)
2020-04-03T06:53:59.1169068Z Downloading task: GitVersion (5.0.1)
2020-04-03T06:54:01.9751642Z Downloading task: DotNetCoreCLI (2.166.2)
2020-04-03T06:54:02.6932173Z Downloading task: PublishBuildArtifacts (1.158.1)
2020-04-03T06:54:02.9584128Z Checking job knob settings.
2020-04-03T06:54:02.9602950Z Finished checking job knob settings.
2020-04-03T06:54:02.9924589Z Start tracking orphan processes.
2020-04-03T06:54:03.0079225Z ##[section]Finishing: Initialize job

- task: DownloadPipelineArtifact@2
  name: DownloadOtherProject
  inputs:
    buildType: 'specific'
    project: 'guid'
    definition: '12345'
    specificBuildWithTriggering: true
    buildVersionToDownload: 'latest'
    artifactName: 'OtherProject StandaloneWindows64'
    targetPath: '$(Pipeline.Workspace)/OtherProject'
- script: echo $(DownloadOtherProject.BuildNumber)

[avivanoff]

@fadnavistanmay, it has been almost two weeks since you closed the bug, but the fix is not in production yet. Please reopen the bug until the fix is actually published.

[avivanoff]

@fadnavistanmay, @jahsu-MSFT, please reopen this bug as task has not been deployed yet after almost a month.

[mmuffins]

Version 2.3.0 rolled out in organization today - and promptly broke a number of our pipelines that were using the step since we used a workaround to get the build number of the downloaded artifact.

In case someone runs into the same issue, we changed

- task: DownloadPipelineArtifact@2
  inputs:
    buildType: 'specific'
    project: xxx
    definition: xxx
    buildVersionToDownload: 'latest'
    artifactName: 'xxx'
    targetPath: '$(Pipeline.Workspace)'

- task: PowerShell@2
  displayName: 'Set Version'
  continueOnError: false
  inputs:
      targetType: 'inline'
      pwsh: true
      script: |
        $resolvedBuildNumber = (([version](az pipelines runs show --id $(BuildNumber) --query buildNumber).Replace("`"","")).ToString())
        $resolvedBuildNumber
        Write-Host "##vso[task.setvariable variable=ComponentVersion]$resolvedBuildNumber"

to

- task: DownloadPipelineArtifact@2
  name: downloadArtifact
  inputs:
    buildType: 'specific'
    project: xxx
    definition: xxx
    buildVersionToDownload: 'latest'
    artifactName: 'xxx'
    targetPath: '$(Pipeline.Workspace)'

- task: PowerShell@2
  displayName: 'Set Version'
  continueOnError: false
  inputs:
      targetType: 'inline'
      pwsh: true
      script: |
        $resolvedBuildNumber = (([version](az pipelines runs show --id $(downloadArtifact.BuildNumber) --query buildNumber).Replace("`"","")).ToString())
        $resolvedBuildNumber
        Write-Host "##vso[task.setvariable variable=ComponentVersion]$resolvedBuildNumber"