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

[OliverRC]

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

[bjorn-ali-goransson]

Agreed. Is there no way to add the arguments? @bishal-pdMSFT

[mustafaoral]

@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

[bishal-pdMSFT]

Agree with @mustafaoral 's suggestion. Although not consistent, it is reasonable workaround. I would love to hear feedbacks though.

[musmuris]

@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!)

[scp-mb]

@mustafaoral Your workaround does not seem to work. It will simply call dotnet.exe pack -c Release --verbosity normal and not pass anything like the packagesToPack parameter

[mustafaoral]

@scp-mb I think while the words I chose weren't incorrect, the example I gave was, slighly. It was a bit misleading due to the inclusion of the packagesToPack parameter, which is ignored when using the custom command.

In my case, I was only interested in being able to provide verbosity level, and the inclusion of the parameter didn't cause any issues; dotnet pack still produced the expected artefact without specifying project or solution file, so I myself was a bit misled as to how the task should be constructed. I've edited my original answer to remove the parameter from the example.

[musmuris]

@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)

[scp-mb]

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

[leomoty]

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.