Replies: 1 comment
-
So I stumbled on this issue #2552 which credit to @samds showed how you can actually still use the MSBuild target tasks to publish MSBuild properties out to Azure DevOps pipelines. #2552 (comment) I think this is how I am going to run given the limitation discovered in #2552 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
So say I have a .NET Standard library. I have installed the
GitVersion.MsBuild
NuGet package. The library dll is built correctly with the version due to the MSBuild target. Great!In the Pipeline (Azure DevOps) I have a task that invokes my powershell script that ultimately invokes:
dotnet build
. I am not using the Azure DevOps tasks to try and have a more portable pipeline that can be run locally (tested debugged).The issue I have is I can't find a nice way to then get at the GitVersion variables in a subsequent script step.
Couple of confusing things I have observed.
Support for CoreCLR with dotnet build is coming soon.
Is that out of date? It seems to be working?WriteVersionInfoToBuildLog
task will attempt to write the information to the current Build Server log. I don't see this happening. If I rundotnet build
with verbosity set todiag
then I can see that sub task is being called and I can see the GitVersion MSBuild properties being set but no where I can see those being emitted to either the output stream or to environment variablesUltimately I want to take the InformationalVersion and use that to rename the pipeline run name with that value.
Is there a way I can tell GitVersion (when I run from dotnet build) to publish it's GitVersion.* variables as environment variables?
Current workarounds:
Beta Was this translation helpful? Give feedback.
All reactions