azure-pipelines-tasks: DotNetCoreCLI - 'pack' does not allow arguments to be passed

Required Information

Entering this information will route you directly to the right team and expedite traction.

Question, Bug, or Feature?
Type: Feature

Enter Task Name: DotNetCoreCLI - pack command should allow arguments to passed like the other commands do.

Environment

Azure Pipelines - Hosted Agent - windows-latest

Issue Description

Currently there is no way to addition arguments to the pack command e.g --no-build --no-restore This is further limiting as one cannot pass MSBuild properties e.g /p:Property

Attempting the following:

- task: DotNetCoreCLI@2
      inputs:
        command: 'pack'
        packagesToPack: 'src/My.Sample.Api/*.csproj'
        packDirectory: '$(Build.ArtifactStagingDirectory)/application'
        versioningScheme: 'off'
        arguments: '/p:NuspecFile=My.Sample.Api.nuspec /p:IsPackable=true --no-build --no-restore'

Does not yield the expected results. The following command is run:

"C:\Program Files\dotnet\dotnet.exe" pack d:\a\1\s\src\My.Sample.Api\My.Sample.Api.csproj --output d:\a\1\a\application /p:Configuration=Release --verbosity Detailed

The arguments are ignored. This is inconsistent with the other commands in the DotNetCoreCLI task like build/restore/etc as mentioned in #9789

The expected result would be

"C:\Program Files\dotnet\dotnet.exe" pack d:\a\1\s\src\My.Sample.Api\My.Sample.Api.csproj --output d:\a\1\a\application /p:Configuration=Release /p:NuspecFile=My.Sample.Api.nuspec /p:IsPackable=true --no-build --no-restore --verbosity Detailed

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 28
Comments: 17 (1 by maintainers)

Commits related to this issue

Configuration release for dotnet pack https://github.com/microsoft/azure-pipelines-tasks/issues/11640#issuecomment-985781667 — committed to microsoft/dev-tunnels by klvnraju 2 years ago

Most upvoted comments

This is definitely annoying for us also, would like to keep using the glob pattern support for finding the projects, but going custom means there is no advantage whatsoever in using the Task anymore.

+10

leomoty on Sep 16, 2020

This issue also extends to the ‘push’ command too.

It is documented that it is not supported but as @leomoty said two years ago, when using the command input set to ‘custom’ we’re unable to pack multiple packages by specifying a glob pattern which reduces how useful this task is.

In my own case, I wanted to set the --skip-duplicate argument on a custom command to push packages as this AzureDevops task does not support arguments when using the ‘push’ command.

However this means that the packagesToPush input cannot be used when the command input is set to ‘custom’. The tradeoff is that multi package upload is not available as there’s no way to specify a glob pattern in a custom command.

My workaround now is instead set the task to continueOnError: true to not throw an error on package push conflicts which is not ideal as it prevents meaningful errors from this task from gating pipelines.

williamoconnorme on Sep 7, 2022

@scp-mb You have to do all the arguments for it to work

e.g. what I use:

- task: DotNetCoreCLI@2
  displayName: Pack
  inputs:
    command: custom
    custom: pack
    arguments: >
      path/to/project.csproj
      --no-build
      -p:PackageId=$(thisPackageId)
      --output $(Build.ArtifactStagingDirectory)
      -p:PackageVersion=$(buildVersion)
      -p:Configuration=$(buildConfiguration)

musmuris on Jun 8, 2020

HI , I try to use script to push nuget,but i get 401 error!!

- script:  dotnet nuget push --source "GWorkOrgPackages" --skip-duplicate  --api-key VSTS --skip-duplicate  '$(Build.ArtifactStagingDirectory)/*.nupkg'
   displayName: 'update nuget pacakge'

Gsonovb on Jun 1, 2023

I find it really annoying that this is, after two years, not fixed? It’s an obvious inconsistency in the usage pattern and we just figured out that we are deploying debug builds to our production environment.

Shame on you Microsoft!

cannehag on Apr 13, 2022

For those who should stumble on this one, like I did, and spend significant amount of time on getting this to work. dotnet pack task for DotNetCoreCLI@2 does not support the arguments parameter in the azure-pipelines.yaml.

BUT for some reason it supports the configuration: 'Release', while neither build nor push do support that (at least I was unable to get it working). So there is lack of consistency, but you can at least get a work around and not use the custom tasks.

laazik on Dec 3, 2021

Thanks for the example @musmuris. Tweaked it to our requirements and that does work fine, which is as expected.

scp-mb on Jun 9, 2020

@bishal-pdMSFT It is a workaround in the sense that you can run the original, find the command line generated and then use custom - but it’s not a very nice workaround. It’s also very confusing when it happens (or at least confused me just now!)

musmuris on Jun 4, 2020

@bjorn-ali-goransson You can use the custom command. This will allow you to specify arguments.

- task: DotNetCoreCLI@2
  displayName: dotnet pack
  inputs:
    command: custom
    custom: pack
    arguments: SampleProject.csproj -c Release --verbosity normal

mustafaoral on Jun 8, 2020