Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build tasks sets the wrong default value to the parameter $ModuleVersion #130

Closed
johlju opened this issue Feb 16, 2020 · 1 comment · Fixed by #131
Closed

Build tasks sets the wrong default value to the parameter $ModuleVersion #130

johlju opened this issue Feb 16, 2020 · 1 comment · Fixed by #131
Labels
bug The issue is a bug.

Comments

@johlju
Copy link
Collaborator

johlju commented Feb 16, 2020

Instead of building the path with the module version 1.0.0 it building the path using the informational version outputted from gitversion, e.g.
1.0.0-add-resource0001+Sha.a60d7ff1210a7eea658d3d3e02fea70a5a2c78c7.Date.2020-02-14.

Change all build tasks to replace the property InformationalVersion with the property MajorMinorPatch. If the InformationalVersion need to be used, then that should be set in another parameter.

This need to be consequent through the build tasks, otherwise it can have consequences in external build tasks like dsccommunity/DscResource.DocGenerator#17.

@johlju johlju added enhancement The issue is an enhancement request. help wanted The issue is up for grabs for anyone in the community. labels Feb 16, 2020
@johlju johlju added bug The issue is a bug. and removed enhancement The issue is an enhancement request. labels Feb 16, 2020
@johlju
Copy link
Collaborator Author

johlju commented Feb 17, 2020

The property MajorMinorPatch does not work since it does not contain the prerelease string. Instead I suggest changing $ModuleVersion parameter to use the GitVersion property NuGetVersionV2 which contain for example the value 0.102.1-fix0001. Then we can add another parameter $InformationalVersion if and when that is needed, there are no build tasks that need it currently. It is not really logical to have that metadata part of a parameter named $ModuleVersion.

Below is the different output from GitVersion:

{
  "Major":0,
  "Minor":102,
  "Patch":1,
  "PreReleaseTag":"fix.1",
  "PreReleaseTagWithDash":"-fix.1",
  "PreReleaseLabel":"fix",
  "PreReleaseNumber":1,
  "WeightedPreReleaseNumber":30001,
  "BuildMetaData":1,
  "BuildMetaDataPadded":"0001",
  "FullBuildMetaData":"1.Branch.fix-debug-moduleversion.Sha.8b2c7e51bec92a02a9dfe50c6cdf822e0bca7853",
  "MajorMinorPatch":"0.102.1",
  "SemVer":"0.102.1-fix.1",
  "LegacySemVer":"0.102.1-fix1",
  "LegacySemVerPadded":"0.102.1-fix0001",
  "AssemblySemVer":"0.102.1.0",
  "AssemblySemFileVer":"0.102.1.0",
  "FullSemVer":"0.102.1-fix.1+1",
  "InformationalVersion":"0.102.1-fix0001+Sha.8b2c7e51bec92a02a9dfe50c6cdf822e0bca7853.Date.2020-02-16",
  "BranchName":"fix/debug-moduleversion",
  "Sha":"8b2c7e51bec92a02a9dfe50c6cdf822e0bca7853",
  "ShortSha":"8b2c7e5",
  "NuGetVersionV2":"0.102.1-fix0001",
  "NuGetVersion":"0.102.1-fix0001",
  "NuGetPreReleaseTagV2":"fix0001",
  "NuGetPreReleaseTag":"fix0001",
  "VersionSourceSha":"620146aa945dde57c6c4243261feaf0727b69806",
  "CommitsSinceVersionSource":1,
  "CommitsSinceVersionSourcePadded":"0001",
  "CommitDate":"2020-02-16"
}

@johlju johlju added in progress The issue is being actively worked on by someone. and removed help wanted The issue is up for grabs for anyone in the community. labels Feb 17, 2020
johlju added a commit that referenced this issue Feb 18, 2020
…release (#131)

- Changed each build task so that the default value of the parameter
  `ModuleVersion` always returns the sematic version (x.y.z-prerelease),
  and not the informational version (issue #130).
@johlju johlju removed the in progress The issue is being actively worked on by someone. label Apr 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant