NuGet Pack doesn't take preview tags from Build.BuildNumber

[jessehouwing]

The NugetCommand Pack task will take a pre-release task when the version is taken from anything, but the Build.BuildNumber. A regex is used to extract the version number from the BuildNumber, which will always strip anything but the 1.1.1.1 parts.

Original regex: https://github.com/jessehouwing/vsts-tasks/commit/5fe31cb19719f9a531aa49c402e4962a687a3aa5#diff-920bb8ed9bf3fa3f695e8b9eb8a14f7eL91

Propose to update the regex with the SemVer allowed pre-release tag regex: https://github.com/jessehouwing/vsts-tasks/commit/5fe31cb19719f9a531aa49c402e4962a687a3aa5#diff-920bb8ed9bf3fa3f695e8b9eb8a14f7eR91

[StandBackBurrito]

As a workaround I am currently setting

Automatic package versioning to Use an environment variable and Environment variable to Build.BuildNumber

[jessehouwing]

Yes, that's what I did too, use environment variable BUILD_BUILDNUMBER does the trick as well. Which is why I found the different behaviour irritating, hence the PR.

[rubenmamo]

@StandBackBurrito thanks for the workaround. That fixed it for me.

I agree that it's confusing. I had to look at the source code of the build step to figure out why it wasn't using it.

[frandi]

I upvote this request. NuGet command pack should respect the pre-release tag in the build number because semver allows it.

[infin8x]

Note to team: we should lmake sure this is fixed for both NuGet and .NET Core.

[StingyJack]

This is not a nice surprise to find, and not the first version changing issue I've had to deal with. Please stop doing/making things that perform unwanted and unexpected version numbering changes. If we specify a version number to use, use it.

[elbatk]

Hello! I'm a PM over on the Azure Artifacts team. I wanted to drop in here and address some of these issues with the news that we're currently reevaluating the types of tasks we offer in Azure Pipelines, and looking to focus more on lighter-weight tasks that cover authentication and setup. In lieu of the task redesign, we're going to forego making changes to the current tasks (with a few exceptions). We hope the new tasks we spin up in the next quarter or so are easier and more helpful, be on the lookout!

[StingyJack]

@elbatk - Are you saying you arent fixing bugs that affect version numbering in a way that removes the pre-release designation and can make those beta packages look like production packages?

Nobody is asking for a change or new feature here. Its a defect that needs to be fixed. Can you make sure that version numbers given to any of the tools you oversee are not modified for any reason?

Focusing on tasks of less value and significantly less usage (who makes an MSI/Setup.exe anymore? What auth is needed that isn't already present?) does not seem like a good idea. MSFT's observed behavior pattern when "Focusing on something else" generally means that the thing not under focus is quickly made into something left broken and not supported.

[elbatk]

Hey @StingyJack , part of the reason that we made the decision to move to the lighter weight tasks is to avoid unexpected behavior that's present in the current, heavier tasks like NuGet. Another reason is that it's hard for users to know if it's our tasks that are behaving oddly or if it's the protocol tools themselves.

I agree with you that this is a defect/bug that should be fixed, but since we aren't investing more into these types of tasks and since there seems to be a workaround so that no one is completely blocked, we don't currently have the bandwidth to update it.

[jessehouwing]

@StingyJack can't we just merge the pull request?

[infin8x]

We can't make this as a minor change because it's technically breaking. If you've built a build that today depends on this logic stripping out the pre-release stuff, we'd break your build with such an update.

As @elbatk mentioned, we're going to simplify these tasks such that you can call NuGet pack directly with whatever parameters you want, including '-Version $(Build.BuildNumber)', so that you get exactly what you're expecting with no task logic in the middle.

[jessehouwing]

But would that then extract the version+tag from the text+version+tag? Like the proposed solution or are we also adding a transform logic?

Yaml is sure starting to look like 2005 msbuild tfsproj...

[infin8x]

Not sure I follow... $(Build.BuildNumber) is whatever you provide as the "Build number format". If you put strings in that build, you would need to extract them with your own regex, that you control. Theme here is getting away from complex, hidden task logic to logic that is visible in your YAML or Designer pipeline that you control.

[StingyJack]

@infin8x - that is the problem here. The task is not taking the value and applying it verbatim like it should. Its stripping the prerelease tag from the end and packages are getting versioned as if they were non prerelease.

This is a pain when the build also does a nuget push into Azure Artifacts where the package can never be deleted, and if someone happens to consume the package it's also a pain to delist it properly.

[StingyJack]

Also, if anyone is relying on the prerelease designation to be stripped out, they probably don't realize it and would appreciate a fix. Even if they don't appreciate it immediately, fixing this would be doing the right thing and removes grounds for complaint.

A POV that defends this version munging for reasons of back compat or breaking changes is about as ludicrous as the position that testfx has about mstest failing to execute tests and not reporting any error to the operator as being something that is even remotely acceptable.

[jessehouwing]

That's what I was afraid of. On one hand the power is infinite with the approach, but the ease of onboarding people a lot less.

The default build number has always had the definition name in it. Which is why this regex has been in the task to begin with. The need to extract the actual version string from another variable probably remains. The current expression syntax in yaml doesn't support regex string extraction as far as I can tell.

So combined, easier for power users, though I suspect many are already using PS, Cake or Grunt to handle their workflow. And a lot less intuitive for the more traditional audience.

And let's be honest, while a breaking change, the current behavior is a bug. Especially as the behavior is not the same between extract from environment variable and from input field. It's just a long standing unfortunate slip-up.

On Wed, 29 May 2019, 00:12 Alex Mullans, notifications@github.com wrote:

Not sure I follow... $(Build.BuildNumber) is whatever you provide as the "Build number format". If you put strings in that build, you would need to extract them with your own regex, that you control. Theme here is getting away from complex, hidden task logic to logic that is visible in your YAML or Designer pipeline that you control.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/azure-pipelines-tasks/issues/6136?email_source=notifications&email_token=AA724SYI4T5DFCY4DL4IERDPXWU6PA5CNFSM4EKHL7U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWNS7MI#issuecomment-496709553, or mute the thread https://github.com/notifications/unsubscribe-auth/AA724SZAIFVP24HDC55EE63PXWU6PANCNFSM4EKHL7UQ .

[infin8x]

As of now, the default build number (in a new YAML build in a new project), retrieved via $(Build.BuildNumber), does not contain the definition name. No regex needed.

I agree that it's a bug. Unfortunately, it's a bug that people depend on. We already tried to fix it once and broke a lot of builds. For every instance like this where a fix seems obvious, there are generally tons of other people using the buggy functionality as-is that we break if we deploy a fix in a minor version.

[StingyJack]

@infin8x then release a major version update of the task so those who want broken can keep the broken version they have.

I dont believe that there are people depending on this bug, any more than I believe there are users who depend on ms test failing to execute tests as a satisfactory thing for them. They can speak up in this thread if they do exist, but currently you have three real users with names that exist in the universe (best as I can reckon) vs. an un-counted population of un-named and thus far non-existent "people that depend on bug".

[infin8x]

As Elijah mentioned, we'll be doing work soon to deprecate these tasks, so we won't be releasing another major version. You can get ahead of that work for your packages with a Command Line task that invokes nuget pack <arguments> -Version $(Build.BuildNumber).

To your feedback above about "Please stop doing/making things that perform unwanted and unexpected version numbering changes. If we specify a version number to use, use it." This is how we're doing that: by taking our heavyweight and opaque task logic out of the way so you can directly call nuget or any other tool and see exactly what's being passed in. You're in full control.

[StingyJack]

@infin8x - so basically you are trimming down to

Users must write their own build scripts, including all the tedious parts like various command syntaxes that they will also be required to learn about in depth just to execute the common task they need.

That doesnt jibe with the general operation of a tool vendor. Usually when those who have been buying and using the tools you provide (for decades) start complaining about a quality aspect of the tools, the response would be to understand those quality issues and improve the product. Instead you are pulling the tools from the market and supplying users the parts so that users may assemble the tool you used to offer. From this conversation I'm getting the impression that this position is rooted in stemming complaints, which makes this position rather childish (smash the toy you dont want to share, and leave it for us to try to put back together). In any case its not in the direction of progress.

You're in full control.

No, I am not when it comes to versioning. Nor when giving commands to some MSFT programs.

I still dont see any backing data showing who those people are that depend on this bug, and it was not addressed further in discussion, so it appears I was given an "alternative fact". Thats not really the way to engender credibility or improve a strained relationship. Fixing the bugs with the tools you have already sold and that are in use would go a long way towards building that credibility and improving that relationship.

[StingyJack]

... and I have no idea or interest in YAML builds. I dont want to use a text editor and CLI for anything I dont have to. When I can hit a key chord to build instead of writing a script to figure out how to execute csc.exe, that is a WIN. That is also PROGRESS. I dont understand this backwards romanticism with raw text editing.

[wangshuai-007]

As Elijah mentioned, we'll be doing work soon to deprecate these tasks, so we won't be releasing another major version. You can get ahead of that work for your packages with a Command Line task that invokes nuget pack <arguments> -Version $(Build.BuildNumber).

To your feedback above about "Please stop doing/making things that perform unwanted and unexpected version numbering changes. If we specify a version number to use, use it." This is how we're doing that: by taking our heavyweight and opaque task logic out of the way so you can directly call nuget or any other tool and see exactly what's being passed in. You're in full control.

How to invoke nuget in CommandLine task? I try Bash、PowerShell、CMD；and all get this error

'nuget' is not recognized as an internal or external command,

nuget : The term 'nuget' is not recognized as the name of a cmdlet, function, script file, or operable program. Check 
the spelling of the name, or if a path was included, verify that the path is correct and try again.

I known it because the nuget is not install in the agent global Or Can you tell me how to get the right nuget installed path? My azure-pipelines.yml is like this:

- task: CmdLine@2
  inputs:
    script: 'nuget pack  **/*.csproj -Version $(Build.BuildNumber) -OutputDirectory $(Build.ArtifactStagingDirectory)'

- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      # Write your PowerShell commands here.
      nuget pack  **/*.csproj -Version $(Build.BuildNumber) -OutputDirectory $(Build.ArtifactStagingDirectory)

[elbatk]

You can use the NuGetToolInstaller task to get NuGet if it's not installed already.

[wangshuai-007]

You can use the NuGetToolInstaller task to get NuGet if it's not installed already.

instead of NuGetToolInstaller task I refer the right dotnet pack command of pipline history I test the follow is ok, show here for everyone need it

task: CmdLine@2
  inputs:
    script: 'dotnet pack --output  $(Build.ArtifactStagingDirectory)  --no-build /p:Configuration=$(BuildConfiguration) /p:PackageVersion=$(Build.BuildNumber) --verbosity Detailed'