TFS Extension Auto-Updating, Extension Version Compatibility List, and Use of Newer api-version Breaks Compatibility with TFS 2017

[mesheets]

Azure DevOps Extension you are using

Set Variable on a Build Definition

Where are you running it?

TFS 2017 Version 15.117.27414.0

Version of Extension/Task

richardfennellBM.BM-VSTS-BuildUpdating-Tasks-1.14.1

Expected behaviour and actual behavior

This issue is somewhat related to issue #497 but is not exactly the same, as will be described below.
Attempting to run the Set Variable on a Build Definition task to increment a build variable fails with the following error message: "Exception calling "DownloadString" with "1" argument(s): "The remote server returned an error: (404) Not Found"

Steps to reproduce the problem

1. Have a version of richardfennellBM.BM-VSTS-BuildUpdating-Tasks that is compatible with TFS 2017 installed on TFS 2017 Version 15.117.27414.0 (e.g. 1.4.1, for which the build at https://dev.azure.com/richardfennell/GitHub/_build/results?buildId=1104 is no longer available).
2. Include the Set Variable on a Build Definition task in a build definition
3. Configure the Set Variable on a Build Definition task to increment a build variable
4. Allow TFS 2017 Version 15.117.27414.0 to run for a period of time (at least a day or more); at some point, it will automatically attempt to update installed extensions (not sure if this might have been triggered sometime following the release of richardfennellBM.BM-VSTS-BuildUpdating-Tasks version 1.14.1); please refer to the links below regarding this extension auto-update functionality.
   • https://social.msdn.microsoft.com/Forums/vstudio/en-US/f6d64e51-5c1b-4c9b-b783-03fc77dfacfb/tfs-2017-buildrelease-extension-updates
   • https://docs.microsoft.com/en-us/visualstudio/releasenotes/tfs2017-relnotes#Marketplace
   • https://social.msdn.microsoft.com/Forums/en-US/ba106320-77e2-4c49-a1ff-a0a1a664db5b/how-can-i-disable-automatic-updates-for-the-onpremise-tfs-2017-marketplace-extensions-
5. The richardfennellBM.BM-VSTS-BuildUpdating-Tasks-1.14.1 extension apparently includes in its metadata that it is compatible with TFS 2017
6. Since there is a new version and richardfennellBM.BM-VSTS-BuildUpdating-Tasks-1.14.1 does not flag that it is incompatible with TFS 2017, TFS automatically updates the richardfennellBM.BM-VSTS-BuildUpdating-Tasks extension to 1.14.1 (as noted in issue Bit Based WIKI Updater - Error: spawn git ENOENT #497, the only real incompatibility is that the api-version is newer than 3.0; however, in testing and troubleshooting related to issue Bit Based WIKI Updater - Error: spawn git ENOENT #497, there did not appear to be any actual dependency in "Set Variable on a Build Definition" requiring the use of a newer api-version, so use of a newer api-version appeared to be unnecessary)
7. Queue the build definition that uses the "Set Variable on a Build Definition" task
8. Build fails with the error message noted in the "Expected behaviour and actual behavior
   " section above

Additional information

Based on testing that was done more specifically in relation to issue #497, it appeared there was nothing within the "Set Variable on a Build Definition" task that actually required use of an api-version newer than 3.0 (c.f. commit 19f489b#diff-765596521f90e301d3fd98e2a7f78de7 ).

Question

Is there any specific known functionality within the latest version of the "Set Variable on a Build Definition" task in the richardfennellBM.BM-VSTS-BuildUpdating-Tasks extension that is known to require use of an api-version newer than 3.0 that perhaps might have been missed when reviewing api-version differences?

[rfennell]

Assuming the older version used to work, it sounds like there is a problem with using the PowerShell3 execution engine for the task.

There has been no functional change to this extension for a year so I suggest you roll back to an older version. The list of versions can be found https://dev.azure.com/richardfennell/GitHub/_build?definitionId=28&_a=summary

[rfennell]

A check does show I missed setting the min agent version

powershell3 handler

• Added in 1.95.1
• Updated in 1.97 to propagate Data property for endpoints

[mesheets]

Yes, running the latest version of TFS 2017, our agent version is 2.122.1.

One of the problems with rolling back (which we have done) is that when TFS 2017 goes out again and checks for updates, it "rediscovers" that there is a new version available, which turns this into a recurring cycle.

On the Marketplace page at https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-BuildUpdating-Tasks , it is currently showing a "Last Updated" time of August 4, 2019, so perhaps might be what triggered this recent spate of automatic extension updates.

Based on discussion in issue #497, it seems version 1.4.1 was figured to be the cutoff for TFS 2017; however, the GitHub version list at https://dev.azure.com/richardfennell/GitHub/_build?definitionId=28&_a=summary doesn't appear to go back that far, and the direct link given in issue #497 of https://dev.azure.com/richardfennell/GitHub/_build/results?buildId=1104 no longer appears to be valid ("Build not found").

I concur with the MSDN post I linked in the initial post above that there should be a way within the server to turn off the completely automatic extension update feature introduced in TFS 2017, but alas....

[rfennell]

There should be no issue with that agent version.

I need to build a TFS 2017 server and give it a try, I don't check older versions on release thee days. Most of the testing (and usage of the tasks) is against Azure DevOps Services

[mesheets]

It seems that perhaps that the hangups might be in the calls the task makes from the build agent to the application tier.

Using commit 19f489b#diff-765596521f90e301d3fd98e2a7f78de7 as an example—

Pre-commit, line 28 was as follows:

$uri = "$($tfsUri)/$($teamproject)/_apis/build/definitions/$($buildDefID)?api-version=2.0"

Post-commit, line 28 was then as follows:

$uri = "$($tfsUri)/$($teamproject)/_apis/build/definitions/$($buildDefID)?api-version=4.0" 

On that same commit web page, lines 77 and 161 were similarly changed from api-version 2.0 to 4.0.

If the value of the api-version query string parameter is "3.0" instead of "4.0", then those web service calls seems to work with Visual Studio 2017. As we have TFS 2017 right now, though, I can't say whether newer TFS / Azure DevOps versions might for some reason require that higher api-version.

[rfennell]

I have a matching test harness that shows the same problem, I can have proper look into it now

[rfennell]

1.15.1 just been shipped this tests fine on TFS 2017 and Azure DevOps

I can't see any obvious reason I moved form 2.0 to 4.0 API calls, sorry for the problems it has caused

[mesheets]

All has been working well now. Thank you for not only providing this fix but also for making these extensions available in the first place.

As an FYI, should anything ever arise in the future necessitating use of an api-version newer than 2.0, it appeared that 3.0 would also work with TFS 2017 (just not 4.0 and above).