Is there a way to enforce this at system level for a Windows Server? I have a number of agents installed on a dedicated Windows Server VM and I’d like all pipelines running on those agents to use the new Node.js version without having to go through each project’s YML definition. Unfortunately I can’t find any documentation regarding AGENT_USE_NODE10. Do I just put that as a new Windows environment variable with “true” as value, or am I naïve to think this will work?
Unfortunately changing the chain for the LE certificate is not an option as the process is handled by Sophos UTM and no additional settings can be provided in there (unless I want to start messing with the UTM’s internal scripts… which I don’t).
I am on the same boat. We have multiple build agents on multiple build servers. Changing every build pipeline does not seem practical.
Also, unfortunately changing the Lets Encrypt cert also is not an option for us.
Do we have any other option/workaround to handle this in better way?
We are in desperate need to resolve this issue.
Update : Adding env variable at the server fixed the SQ tasks but broke the other tasks which are dependent on older version of NODE. So this is clearly not a good workaround.
When are you guys planning to push the fix for this issue?
Maybe some sort of chart on the recommendations would be of help.
First, if you are able to fix the certificate chains, then that would fix the issue, regardless of what version of the DevOps extension you have. It will probably also fix a lot of other issues brought about by the expired root certificate.
If the above is not feasible due to infrastructure restrictions or limitations, then the next step depends on what version of the DevOps extension you have.
If on v4.23.0, then you’d only need to make sure that your agent is at 2.144.0 or later because the DevOps extension v4.23.0 requires this. Note that even if you don’t use HTTPS connectivity to the SonarQube server, but your DevOps extension got updated to v4.23.0, you’d still need to ensure that your agent is at 2.144.0 or later. Otherwise, the extension/task will fail.
If on v4.23.1 and using HTTPS, then you’d have to be able to set the environment variable AGENT_USE_NODE10 and make sure that your agent is at 2.144.0 or later. The environment variable is only recognized by agent version 2.144.0 or later. I mentioned that there are inherent risks to this, because when you set the environment variable, all other DevOps extensions will be targeted to use Node10 and those other extensions might not be compatible running with Node10, in which case you’re now gonna be trying to figure out how to fix the other extensions.
If on v4.23.1 and using HTTPS, but you are restricted/limited from setting the environment variable and ensuring your agent is at 2.144.0 or later, then you’re out of luck. Might need to figure out how to downgrade to v4.23.0 or wait for that new MAJOR version that they’re coming up with (which will also require agent 2.144.0 or later anyway).
Again apologies for the pain this is causing, I hope you’ve found a solution with the workarounds. Thanks @peter_w for sharing your clarifications. The new version is looking like a few weeks away, we’ll do our best to get it out as soon as we can.
For us the workarounds are some breathing space. But not on all of our builds. So I really hope the new version will be here soon. Because our company has a LOT of pipelines and the only fix working is the usenode10 var which isn’t the best solution because it has broken some of the pipelines and needs to be deleted on all pipelines again if the new version comes.
Well to say the least, the new major version will also need a manual actions on all of your pipelines, but this one shall not be temporary compare to the env variable to set.
Upgrading to v5 of the plugin showed the same issue.
Turns out that just before the SSL cert issue we were almost at the default post size limit of nginx.
During the time that we had the Azure plugin disabled we had breached the max post size and so when we used the work-around it failed with a new error.
i’m getting the same error, and i don’t know how to solve it. We tried restoring the token, and reinstalling the extension, because we installed last Friday and worked perfectly, but today it doesn’t work anymore.
Hello, I am having the same issue that started yesterday, this was still working on June 23, 2022.
I was using 4.x version of prepare analysis and was even moved to version 5.x but having the same issue. I am using Azure devops plugin.
This is what I am getting:
##[error][SQ] API GET ‘/api/server/version’ failed, error was: {“code”:“CERT_HAS_EXPIRED”}