[ISSUE]: Arbitrarily high Build Agent Version demand required to run tasks?
Prerequisites
- [x] I have written a descriptive issue title
- [x] I have searched issues to ensure it has not already been reported
GitVersion package
AzureDevops task
What are you seeing?
I recently had my Azure DevOps Server administrators install this extension into a collection so I can start playing around with it. Unfortunately, however, it seems that this extension places a demand for a (seemingly) high Build Agent version demand.
We often lag behind "the bleeding edge" of agents (OK, even more behind than the bleeding edge), with our highest running version being 2.181.2. Even the latest and greatest versions of Jfrog CLI, Octopus Deploy, AWS, Terraform, and many other extensions run on our agents, which arguably, do A LOT MORE than this extension does. So why such a high build agent version demand that limits where this extension can be run?
This is very unfortunate, as GitVersion is an awesome versioning tool that is now EXTREMELY difficult to use in our build environment. 😢
What is expected?
I expect that this tool should "just work" on almost any version of the Azure DevOps build agent that's out there. What it does is relatively simple: executes some git commands and adds variables to the build environment. This has been supported by the build agents "almost forever", so there's really no need (other than Azure DevOps TypeScript library compatibility) to restrict on what version of Agent this can run, at least, not as "high" of a restriction.
Steps to Reproduce
- Install a build agent with v2.181.2 (or older)
- Add GitTools extension to the Azure DevOps Collection/Organization
- Create a build pipeline with only the task to install the GitVersion tool
- Run the pipeline
- Not profit 😢
Output log or link to your CI build (if appropriate).
##[error]No agent found in pool BuildAgentPoolTest01 which satisfies the following demand: Agent.Version. All demands: Agent.Version -gtVersion 3.224.0 Pool: BuildAgentPoolTest01 Started: Today at 1:16 PM Duration: 10m 57s
Job preparation parameters ContinueOnError: False TimeoutInMinutes: 60 CancelTimeoutInMinutes: 5 Expand: MaxConcurrency: 0 ########## System Pipeline Decorator(s) ##########
Begin evaluating template 'system-pre-steps.yml' Evaluating: eq('true', variables['system.debugContext']) Expanded: eq('true', Null) Result: False Evaluating: resources['repositories']['self'] Expanded: Null Result: False Finished evaluating template 'system-pre-steps.yml'
Template and static variable resolution complete. Final runtime YAML document: steps: []
MaxConcurrency: 0 1 queue time variable used system.debug : false
This may be related to #1231.
@fourpastmidnight you can always use the GitVersion.tool directly, or you can use older version of the extension like 1.0.0 which uses the latest v2.220.0 version released back in April 2023. Most of the users of this extension (me included at some point) are using the Microsoft Hosted Agents, and most probably they are running the most recent version of the agents. Second reason to keep up to date with the newer releases of the agents is the dotnet version they are running on are getting out of support as well. For example the v2 series of agents are not released anymore and that is because they were build on top of .netcoreapp3.1 which is out of support for several years. the v3 series is build on top of .net60 which is soon out of support like in a week so that means the v3 will become out of support not that long from now. Whenever we switch the agent to a different series of agents we also upgrade the extension version as well. So the only option for you would be for you to use version v2.220.0 of the agent and use version 1.0.0 of the extension.