SonarQube VSTS Extension v4.23.0 Fails to Launch

We have a local TFS Version 16.131.27701.1 instance that is triggering SonarQube scans. We installed the SonarQube VSTS Extension a number of years ago. For the last 2.5 years (at least), things have been running very well. I have the build task set up to use 4.* as the version - the drop down only allows that specificity.

Three hours ago, builds started failing. The “Prepare Analysis on SonarQube” step fails to load. Here is the log output from the task:
2021-10-01T19:03:48.3438370Z ##[section]Starting: Prepare analysis on SonarQube
2021-10-01T19:03:48.3633096Z ==============================================================================
2021-10-01T19:03:48.3633388Z Task : Prepare Analysis Configuration
2021-10-01T19:03:48.3633734Z Description : Prepare SonarQube analysis configuration
2021-10-01T19:03:48.3634033Z Version : 4.23.0
2021-10-01T19:03:48.3634209Z Author : sonarsource
2021-10-01T19:03:48.3634445Z Help : Version: 4.23.0. More Information
2021-10-01T19:03:48.3634683Z ==============================================================================
2021-10-01T19:03:48.3892385Z ##[error]A supported task execution handler was not found. This error usually means the task does not carry an implementation that is compatible with your current operating system. Contact the task author for more details.
2021-10-01T19:03:48.3920301Z ##[section]Finishing: Prepare analysis on SonarQube

I tried stepping it down to the 3.* version, but - besides being deprecated - the /sonar-project.properties file could not be found…

No one in the organization is fessing up to updating the version of this plugin. But three hours ago - the latest successful build log shows that version 4.22.0 of this task was being called.

Any help about how to get around this is appreciated. Is there something I can alter in the build configuration to get it to find the right handlers?

Thanks!

1 Like

Hey @chicadilly

Microsoft auto-updates extensions so no need to hunt for somebody responsible!

What build agent version is used on the affected build agents?

hi @Colin

I’m having the same issue – my agent is running on version 2.131.0.
i have the same sonarqube analysis is 4.23.0

can you help us on the work around?

thank you

Hi there,

We had to bump this node handler for some certificate reason. You may then need to upgrade your build agent to version 2.144.0 in order to make it work. Can you check if that one can be installed on your instance ?

HTH,
Mickaël

1 Like

I’m having the same issue – my agent is running on version 2.122.1 and TFS 2017 update 3.
2.122.1 is the latest for this versions of TFS.
I have the same Sonarqube analysis is 4.23.0 an tried with 3.21.0 as well.

Can you help us on the work around?

Thank you
Raghu

Greetings folks,

Thank you again for reaching out.

Last Friday, a new release of the Extension for Azure DevOps was published to address this issue. This required making sure the tasks began to run on a NodeJS 10 runtime.

What we did not anticipate was that this would require a newer version of the build agent than the versions of TFS/Azure DevOps that the extension declares compatibility with.

For now, as we sort out the best way forward on our side, there are two potential workarounds:

  • Manually install newer versions of the Azure Pipelines Agent on your build servers (at least newer than v2.144.0 ). We cannot guarantee the compatibility of newer versions of the build agent with the version of TFS / Azure DevOps you are using.
  • Remove the existing version of the extension ( v4.22.0 ) and manually install an old version of the Extension for Azure DevOps ( v4.22.0 which does not include the changes made last Friday. Documentation for managing extensions can be found here. Uninstalling the extensions snd installing a new (well, old) version will preserve the tasks configured for existing pipelines.
    • You may need to clear the _ work directory of existing agents to ensure the newer task version is not cached

If you choose to use one of these workarounds, please let us know which one you choose. In the meantime, if you face this issue, please let us know what version of TFS / Azure DevOps you are using.

We will keep you posted in case of any updates.

Best regards,

Colin

1 Like

That was the problem! We are running version 2.131.0 of the TFS agent. We updated one machine to use v2.193.0 of the agent and that worked! Now we’re in the process of updating the rest of the pool.

Thanks so much!

1 Like

Upgrading the Agent to latest (2.193.0) is working.

With TFS 2017 v15.117.27414.0, the latest agent version is 2.122.1. We get the “A supported task execution handler was not found” issue as well with extension v4.23, but v4.22 of the extension ran fine.

If we remove and manually install the older v4.22, won’t TFS auto-update it? Is there any other workaround, or a patch for v4.23 in works?

Thank you @mickaelcaro

Installing that version works

sorry, my browser not updated – I see Raghu is able to install with latest version.

Hi @jfoster2020
If you install the extension manually (by providing vsix) i don’t think this will get automatically updated.

Thanks All
Upgrading our build agents to 2.193.1 version solve the issue

1 Like

Will doing the initial uninstall of the extension cause all of the tasks that are setup in a build definition be wiped or will everything remain in place?

We are running TFS2018 and were running agent 2.136.1 upgraded to 2.190.0 which solved the issue.

Hi @prketner

No everything will remain in place, it’s just that if you have pipeline running in the mean time, they will fail.

Mickaël

Hi @mickaelcaro ,
your downgrade of the node handler made the plugin unusable for users of Azure DevOps (SAAS) again. People using outdated / on prem solutions may just shouldn’t install the plugin >4.22 as you can’t stick to a specific version in azure devops. It installs automatically the latest version.
https://jira.sonarsource.com/projects/VSTS/issues/VSTS-261?filter=allissues

Guess people using old software have to live with the fact that not all plugins are running there all the time.

Now you have “fixed” the plugin for users who manually can decide to ignore the fix - but broke it again for all the others who don’t have any chance to stick on 4.23.0

And just another question - what happens to users which are using TFS 2017 and let’s encrypt certs ? - It wont work there either.