You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched issues to ensure it has not already been reported
GitVersion package
GitVersion.Tool
GitVersion version
Any
Operating system
Windows
What are you seeing?
When using the gitversion/setup@0 (or gitversion/setup@1), GitVersion tasks within an Azure DevOps, YAML pipeline, specifically when using a wildcard, versionSpec value, like so...
...it seems that the GitVersion Setup task/step is still trying to connect externally/online to download a version of the package/tool.
This has been noticed on an internal/self-hosted, Azure DevOps, build agent that does NOT have access to the internet (and therefore any public, NuGet/package repositories), and where build tools are typically installed into the Azure DevOps agent, tool cache directory, within the (default) <agent_install_directory>/_work/_tool directory, so they can be found/installed without accessing the internet.
In this case, we have copied/setup a version (5.6.11, in this case) of GitVersion.Tool within the tool cache, but using the versionSpec of 5.x fails to find the package/tool in the cache.
It seems that if the full/exact version is fixed/defined explicitly (e.g. versionSpec: '5.6.11') then the GitVersion task successfully finds the cached/installed tool, and does NOT attempt to download the cache. For example...
If a local, cached version of the GitVersion.Tool exists, that would be expected to match the wildcard value provided in the versionSpec property (e.g. Version 5.6.11 is in the cache/directory, and versionSpec of 5.x is provided), then the GitVersion setup task should be finding the cached version of the package, and NOT trying to connect to the internet (and related, public package feeds) to attempt to download the tool.
Only when NO version in the Azure DevOps agent, tool cache matches the wildcard-versionSpec, should GitVersion attempt to download from the internet.
Steps to Reproduce
Setup/Use a build server that does not have public/internet access
Setup a copy/version (e.g. 5.6.11) of the GitVersion.Tools tool in the location of the Azure DevOps, Agent.ToolDirectory (tool cache)
Setup an Azure DevOps, YAML pipeline using the gitversion/setup@0 or gitversion/setup@1 tasks, where the versionSpec property uses a wildcard (seems to need to use x not *, but neither work), like this:
Prerequisites
GitVersion package
GitVersion.Tool
GitVersion version
Any
Operating system
Windows
What are you seeing?
When using the
gitversion/setup@0
(orgitversion/setup@1
), GitVersion tasks within an Azure DevOps, YAML pipeline, specifically when using a wildcard,versionSpec
value, like so......it seems that the GitVersion Setup task/step is still trying to connect externally/online to download a version of the package/tool.
This has been noticed on an internal/self-hosted, Azure DevOps, build agent that does NOT have access to the internet (and therefore any public, NuGet/package repositories), and where build tools are typically installed into the Azure DevOps agent, tool cache directory, within the (default)
<agent_install_directory>/_work/_tool
directory, so they can be found/installed without accessing the internet.In this case, we have copied/setup a version (
5.6.11
, in this case) ofGitVersion.Tool
within the tool cache, but using theversionSpec
of5.x
fails to find the package/tool in the cache.Related Links
Workaround
It seems that if the full/exact version is fixed/defined explicitly (e.g.
versionSpec: '5.6.11'
) then the GitVersion task successfully finds the cached/installed tool, and does NOT attempt to download the cache. For example...What is expected?
If a local, cached version of the GitVersion.Tool exists, that would be expected to match the wildcard value provided in the
versionSpec
property (e.g. Version5.6.11
is in the cache/directory, andversionSpec
of5.x
is provided), then the GitVersion setup task should be finding the cached version of the package, and NOT trying to connect to the internet (and related, public package feeds) to attempt to download the tool.Only when NO version in the Azure DevOps agent, tool cache matches the wildcard-
versionSpec
, should GitVersion attempt to download from the internet.Steps to Reproduce
Setup/Use a build server that does not have public/internet access
Setup a copy/version (e.g.
5.6.11
) of theGitVersion.Tools
tool in the location of the Azure DevOps,Agent.ToolDirectory
(tool cache)Setup an Azure DevOps, YAML pipeline using the
gitversion/setup@0
orgitversion/setup@1
tasks, where theversionSpec
property uses a wildcard (seems to need to usex
not*
, but neither work), like this:ECONNRESET
message/error.RepositoryFixture Test
(Not provided)
Output log or link to your CI build (if appropriate).
The text was updated successfully, but these errors were encountered: