[ISSUE]: Gittools Azure DevOps task 3.0.4 unable to retrieve gitversion output variables value or set version

[xlreme]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

AzureDevops task

What are you seeing?

Platform: Azure DevOps Task
GitTools: 3.0.4
GitVersion: 5.12.0

Unable to output the value for GitVersion.SemVer, GitVersion.NugetVersion and etc in the next subsequent Azure Devops tasks.

This is working in GitTools 3.0.3 and below

What is expected?

The next subsequent Azure DevOps Task should be able to retrieve the GitVersion output values after running gitversion/setup & gitversion/execute tasks.

Steps to Reproduce

1. Use Azure DevOps task gitversion/setup@3 or gitversion/[email protected], use input, version spec "5.x"

2. Use Azure DevOps task gitversion/execute@3 or gitversion/[email protected]

3. Next, use bash task to output $(Gitversion.SemVer)and note the output.

Output log or link to your CI build (if appropriate).

[davidkeaveny]

This issue is related to the change implemented in v3.0.4; there are some further comments there.

[arturcic]

@xlreme you can use $(Gitversion_SemVer) instead https://github.com/GitTools/actions/blob/main/docs/examples/azure/gitversion/execute.md#example-7

[egaudry]

killing of v3.0.4 would allow to restore Azure DevOps service (and possibly others) in no time, is this something we can discuss to mitigate the issue @arturcic @davidkeaveny ?

[Sharparam]

Why was a breaking change released in a patch version?

Edit: Oh I think I misread it as removing /output buildserver from the GitVersion tool itself, but it's just removing it when calling it from the action.

[arturcic]

It should not have been a breaking change, it's a regression, and it should be a minor

[mogrodnv]

Could someone elaborate on the original change? In the PR it just says that "it's duplicating the actions behavior". What does that mean in practical terms?
What is instead expected to happen?

And now as build pipelines are going "boom, boom, boom" all over the world, why hasn't the "3.0.4" version been withdrawn while working on a fix? We're all now implementing workarounds, whether its specifying "@3.0.3" in our YAML pipelines or selecting "2.*" in our classic pipelines (yeah, those still exist..).

[gittools-bot]

🎉 This issue has been resolved in version v3.1.0 🎉
The release is available on:

• GitHub Release

Your GitReleaseManager bot 📦🚀

[arturcic]

please confirm it works for you all @davidkeaveny @xlreme @mogrodnv @egaudry

[mogrodnv]

please confirm it works for you all @davidkeaveny @xlreme @mogrodnv @egaudry

An Azure DevOps pipeline run with "gitversion/setup@3" still downloads the 3.0.4 version:

2024-12-10T13:41:50.2923460Z Downloading task: gitversion/setup (3.0.4)
2024-12-10T13:41:50.3843647Z Downloading task: gitversion/execute (3.0.4)

I guess we need to give it some time to be detected by ADO.

[IgorMikhalev]

I am able to use the latest version of the task.

The pipeline build version is updated after switch from 3.0.4 to 3.1.0. However I am still not able to use variables, which was possible with 3.0.3

Pipeline:

    - bash: |  
        versionNumber="$(GitVersion.AssemblySemVer)"
        informationalVersion="$(GitVersion.InformationalVersion)"

Result:

/home/vsts/work/_temp/2e9626f8-6a18-4721-879e-04b7e4e8793e.sh: line 1: GitVersion.AssemblySemVer: command not found
/home/vsts/work/_temp/2e9626f8-6a18-4721-879e-04b7e4e8793e.sh: line 2: GitVersion.InformationalVersion: command not found

[arturcic]

please replace $(GitVersion.AssemblySemVer) with $(GitVersion_AssemblySemVer)

[IgorMikhalev]

please replace ( G i t V e r s i o n . A s s e m b l y S e m V e r ) w i t h (GitVersion_AssemblySemVer)

Issue solved.
Thank you for the quick response and the issue fix.

[mogrodnv]

I haven't retried a run yet, but have an other comment: If we have to start changing the way we reference these "$(GitVersion.xxx)" pipeline variables (from a dot to an underscore), then this is definitely not a minor issue any more. Then it's still a breaking change, needing a major version bump of the tool version. Or am I missing something? Is there an updated readme that explains this change?

[Ilia-Kosenkov]

We use more than one gitversion output via $(GitVersion.XXX) syntax. Is there a list of replacements that I can use for migration?

[arturcic]

OK, I will add back additional duplicated variables, with the dot syntax, but that will be removed in v4. The reason for removing is to be consistent with the GitVersion tool

[aroksa]

Yeah, changing the output variable names broke my builds this morning as well - those variables are the entire reason I use the task, so changing how they're accessed is always going to be a major breaking change. I updated my templates to use the _ and everything is working, but that was quite a bit of lost time for people this morning.

[ondrej-hegedus]

OK, I will add back additional duplicated variables, with the dot syntax, but that will be removed in v4. The reason for removing is to be consistent with the GitVersion tool

Measure twice times before cutting once.

[Ilia-Kosenkov]

Thanks @arturcic . I did a quick search and did not find information about adopted versioning strategy, but if it is semver, then changing public contract falls and a major change, i.e. 3 -> 4. Since most people reference tasks as Task@N, introducing breaking change with new major version would not have caused this cascade of broken CIs.

[arturcic]

OK, I will add back additional duplicated variables, with the dot syntax, but that will be removed in v4. The reason for removing is to be consistent with the GitVersion tool

Measure twice times before cutting once.

I don't think this is a valuable remark, does not help with the motivation of any open source projects, especially for those that are not paid for. I would prefer to have the support on maintaining or at least testing the project and not this kind of remarks.

[mogrodnv]

Let's all be friends. We all appreciate the effort @arturcic and others are putting into this and other open source projects, unpaid as it is.
I think this time, we got caught "a bit" off guard, by what was only labelled as a patch release, even.

It's not easy to maintain such super-important tools, as shown in this immortal comic:
xkcd dependency

That said, what I personally saw as the most "annoying" with this change, if you like - still trying to be friends - is that I didn't quite grasp the why. And I guess I still haven't fully.
Through some of the comments and the original PR, and the changes made in the last PR, I've sort of deduced that the tool should stop outputting those dot-based pipeline variables we've come to love throughout the years.

I don't exactly mind doing it differently - in a major version, that is - I just need to understand what benefit it yields, for myself or ultimately for the tool authors, for that matter.
Some more elaborate explanation would still be appreciated.

[arturcic]

I don't exactly mind doing it differently - in a major version, that is - I just need to understand what benefit it yields, for myself or ultimately for the tool authors, for that matter.
Some more elaborate explanation would still be appreciated.

Agree with that. will try to communicate better

[arturcic]

version v3.1.1 is out, please have a new try

[ondrej-hegedus]

OK, I will add back additional duplicated variables, with the dot syntax, but that will be removed in v4. The reason for removing is to be consistent with the GitVersion tool

Measure twice times before cutting once.

I don't think this is a valuable remark, does not help with the motivation of any open source projects, especially for those that are not paid for. I would prefer to have the support on maintaining or at least testing the project and not this kind of remarks.

You really have my support and support of many other people. You can bet, we are thankful for it.
What I want to morally support you even more is, to carefully plan the design of breaking changes.
I think it's understandable how unpleasant it is to see thousands of pipelines breaking, because of a minor change.

[mogrodnv]

version v3.1.1 is out, please have a new try

I can confirm that using "gitversion/execute@3" once more works, using our dot-based pipeline variables:

2024-12-10T15:35:35.7689763Z Task         : Execute GitVersion Task
2024-12-10T15:35:35.7689826Z Description  : Easy Semantic Versioning (https://semver.org) for projects using Git
2024-12-10T15:35:35.7689931Z Version      : 3.1.1
[...]
2024-12-10T15:36:16.6741138Z GitVersion executed successfully
2024-12-10T15:36:16.6744552Z ##[section]Async Command Start: Update Build Number
2024-12-10T15:36:16.7088365Z Update build number to 11.0.0-debt-626220-gitver-rev.1+17 for build 1733349
2024-12-10T15:36:16.7088620Z ##[section]Async Command End: Update Build Number

I will now start doing the migration from dot to underscore, so that I'm ready in due time for the upcoming "4.x" version.

PS. Speaking of that "4.x" version, I also git bit by an other GitVersion issue today, as I'm adventurous and let the "gitversion/setup" task download whichever version happens to be the latest, because why not (well, I know now why not...):

      - task: gitversion/setup@3
        inputs:
          versionSpec: "x"

When running that, it gave me version "6.1.0" of the underlying "dotnet-gitversion" executable, instead of "6.0.5" yesterday.
Turns out that "6.1.0" can't be used with the "3.x" series of "gitversion/setup":

Acquiring GitVersion.Tool for version spec: x
--------------------------
Querying tool versions for GitVersion.Tool@x 
Found matching version: 6.1.0
##[error]Version spec 'x' resolved as '6.1.0' does not satisfy the range '>=5.2.0 <6.1.0'.See https://github.com/GitTools/actions/blob/main/docs/versions.md for more information.

Indeed, the referenced "versions.md" file has a table that details this.
However, there's (yet) no "4.x" series to download, so feels somewhat inconsistent.
But I'm a patient guy, so for now I've adjusted my "adventurousness", and currently specifying "6.0.x" instead.

What's the link between these tools, really? Are you @arturcic a maintainer of "dotnet-gitversion" as well?

[arturcic]

What's the link between these tools, really? Are you @arturcic a maintainer of "dotnet-gitversion" as well?

Yes, but this repository has also support for GitReleaseManager which is part of our OSS organization, but I don't actively maintain that tool. The reason v4 is not yet release is because there were several fixes that were related to this repo and not the GitVersion itself and they ended up in the v3 release. v4 drops support for GitVersion 5.12 as well as 6.0 as those versions use deprecated version of dotnet.

It's still hard for me to come up with a proper versioning policy as there are several things I need to play with - GitVersion.Tool, GitReleaseManager.Tool version, as well as the nodejs version and AzureDevops agents version. That's why I created that versions.md file where kind of a mapping between all these dependencies is created.

[arturcic]

so v4 this come shortly after v3 is more or less stable again

[erenken]

I'm sorry I think this is related, but not 100% sure. I am getting this error in my Azure DevOps Pipeline.

Starting: GitVersion Execute
==============================================================================
Task         : Execute GitVersion Task
Description  : Easy Semantic Versioning (https://semver.org/) for projects using Git
Version      : 3.1.1
Author       : GitTools Contributors
Help         : See the [documentation](https://gitversion.net/docs/) for help
==============================================================================
Running on: 'Azure Pipelines'
Disable Telemetry
Command: /opt/hostedtoolcache/GitVersion.Tool/5.12.0/dotnet-gitversion /home/vsts/work/1/s /output json /l console /config /home/vsts/work/1/s/GitVersion.yml
##[error]Unable to process command '##vso[task.setvariable variable=GitVersion.Major;isOutput=true;issecret=false;]0' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)

This is what my YAML looks like:

    - task: gitversion/setup@3
      displayName: GitVersion Setup
      inputs:
        runtime: 'core'
        versionSpec: '5.x'
    - task: gitversion/execute@3
      displayName: GitVersion Execute
      name: gitVersion
      inputs:
        runtime: 'core'
        disableShallowCloneCheck: true
        useConfigFile: true
        configFilePath: 'GitVersion.yml'

When I change it to:

    - task: gitversion/[email protected]
      displayName: GitVersion Setup
      inputs:
        runtime: 'core'
        versionSpec: '5.x'
    - task: gitversion/[email protected]
      displayName: GitVersion Execute
      name: gitVersion
      inputs:
        runtime: 'core'
        disableShallowCloneCheck: true
        useConfigFile: true
        configFilePath: 'GitVersion.yml'

It works fine.