[BUG]: DotNetCoreCLI@2 "pack" discards pre-release tag when using `versioningScheme: 'byBuildNumber'`

[heidemn-faro]

New issue checklist

• I searched for existing GitHub issues -> #13509 (stale & closed)
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

NuGetCommand@2 | DotNetCoreCLI@2

Task version

2.259.0 | 2.263.0

Issue Description

A bug happened! It has been reported before, but for some reason it wasn't fixed.
#13509

What we're doing:

          - task: gitversion/setup@0
          - task: gitversion/execute@0
          - task: DotNetCoreCLI@2
            displayName: 'NuGet Pack SDK'
            inputs:
              command: pack
              packagesToPack: './src/app/Files.xxxxxxx/Files.xxxxxx.csproj'
              packDirectory: '$(Build.ArtifactStagingDirectory)'
              versioningScheme: 'byBuildNumber'

# With NuGetCommand@2 I believe we had the same problem.
# Let me double-check and then update this with more information.

GitVersion/Execute:

Update build number to 1.0.26-DDP-168-push-digitaldeliverydev.2 for build 12377

The variable $(Build.Number) is set as expected, and also reflects Azure DevOps UI.
However the pre-release suffix is silently dropped by DotNetCoreCLI@2:

DotNetCoreCLI@2

Starting: NuGet Pack SDK
==============================================================================
Task         : .NET Core
Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version      : 2.263.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
/opt/hostedtoolcache/dotnet/dotnet pack /home/vsts/work/1/s/src/app/Files.xxxxx/Files.xxxxx.csproj --output /home/vsts/work/1/a /p:Configuration=Release /p:PackageVersion=1.0.26 --verbosity Normal
MSBuild version 17.7.6+77d58ec69 for .NET

Workaround

We've found a workaround, but the above way (byBuildNumber) should work as well.

          - task: DotNetCoreCLI@2
            displayName: 'NuGet Pack SDK'
            inputs:
              command: pack
              packagesToPack: './src/app/Files.xxxxx/Files.xxxxx.csproj'
              packDirectory: '$(Build.ArtifactStagingDirectory)'
              versioningScheme: 'byEnvVar'
              versionEnvVar: 'Build.BuildNumber'

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

ubuntu-latest

Relevant log output

Starting: NuGet Pack SDK
==============================================================================
Task         : .NET Core
Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version      : 2.263.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
/opt/hostedtoolcache/dotnet/dotnet pack /home/vsts/work/1/s/src/app/Files.xxxxx/Files.xxxxx.csproj --output /home/vsts/work/1/a /p:Configuration=Release /p:PackageVersion=1.0.26 --verbosity Normal
MSBuild version 17.7.6+77d58ec69 for .NET

Full task logs with system.debug enabled

 [REPLACE THIS WITH YOUR INFORMATION] 

Repro steps

On ubuntu-latest:

• Set Build.Number to 1.0.26-DDP-168-push-digitaldeliverydev.2
• Run this:

          - task: DotNetCoreCLI@2
            displayName: 'NuGet Pack SDK'
            inputs:
              command: pack
              packagesToPack: './src/app/SomeProject/SomeProject.csproj'
              packDirectory: '$(Build.ArtifactStagingDirectory)'
              versioningScheme: 'byBuildNumber'

• Expected: NuGet package gets version 1.0.26-DDP-168-push-digitaldeliverydev.2
• Actual: NuGet package gets version 1.0.26

[github-actions]

In order to consolidate to fewer feedback channels, we've moved suggestions and issue reporting to Developer Community.

[heidemn-faro]

In order to consolidate to fewer feedback channels, we've moved suggestions and issue reporting to Developer Community.

@v-schhabra (under the assumption that you're a MSFT employee) - This automated comment sounds to me like: "In order to make it harder for people to report bugs, we've moved the bug reporting from the most commonly used platform (Github) somewhere else." Convince me of the opposite 😈

To give constructive feedback, I see two main options to fix it:

• Make versioningScheme: 'byBuildNumber' take the full version string.
  Disadvantage: Every change breaks someone's workflow.
• Introduce a new versioningScheme: 'bySemVerBuildNumber' as suggested here: NugetCommand@2 versioningScheme: byBuildNumber truncates a build number with a hyphen #13509 (comment)
  "add a new case named something like bySemVerBuildNumber, and check if it is semver 2.0 compatible, else fail the task and thereby the build."
  Since this is non-breaking, it could be added in a minor release of the tasks.

In any case, the docs don't mention the current special behavior.
So if byBuildNumber continues to behave like this, it would be nice if you could at least update the docs, to save future developers some time.
Current docs:

byBuildNumber - Use the build number: The task will use the build number to version the package.

Thanks :-)