Closed sevaa closed 1 year ago
The immediate cause of my issue is that _getApiVersion VariableGroups
returns a blank string for my TFS; as a result, the URL for the variable getting misses the api-version parmeter and goes "https://tfs.niaid.nih.gov/tfs/Admin//AMBIS/_apis/distributedtask/variablegroups&groupName=Configuration"
.
The real bug is that the URL generation logic in _buildRequestURI
produces a malformed URL if a blank api-version and a nonblank query string object is passed.
Yet another bug is that _appendQueryString
unconditionally adds a & separator, even if the query string was originally empty. Normally it would have the api-version, but if the api-version is blank, _appendQueryString
can't be used as is.
Looks like the root cause is that the Set-VSTeamAccount is not resolving the version of my on prem TFS instance and is not feeding the right set of api-version values. If the first line goes instead
Set-VSTeamAccount "http://tfs.acme.com:8080/tfs/MyCollection/" -UseWindowsAuthentication -Version AzD2019
That resolves the issue. Still, not cool.
On a side note, the notion that on-prem TFS is presumed to be TFS2017 - see _getVSTeamAPIVersion
- is also rather questionable. That's a five year old version, soon to be unsupported. Maybe the module should try and interrogate the instance? That's a design decision above my pay grade, though.
Steps to reproduce
Expected behavior
A group record
Actual behavior
Error message with a large HTML along the lines of "error 404"
Retrieval by ID works.
If you set the project by
Set-VSTeamDefaultProject
, same result.Environment data
OS
Server