Re-add getting sonar project parameters from build log feature

[kumbasar]

As stated in SonarQube integration fix, the merge as broken our integrity between SonarQube and InfluxDb.

Therefore, we re-add the getting sonar parms from the build log.

Tests logs fine:

• [x ] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[asimell]

Did you also try this with release 3.1.1, where I introduced a fix for this issue (#128)? Or does the issue still persist?

[kumbasar]

Did you also try this with release 3.1.1, where I introduced a fix for this issue (#128)? Or does the issue still persist?

Yes, 3.1.1 didn't resolve this issue. I have replayed the same pipeline with v3.1.1:

IMHO, the root cause is that the plugin is searching the report-task.txt in the Jenkins main node, not in the Jenkins agent.

[cburne-oshyn]

I have same issue in 3.1 and 3.1.1. I have tried manually setting WORKSPACE to the location on the node and it still does not seem to find report-task.txt. I am sure I'm getting the report-task.txt file on the node b/c I'm outputting it to my log file

Also, I am using Windows Jenkins nodes and I'm using the SonarScanner for MSBuild build tool to do my scan. I don't think that shoudl be an issue, but since I see it's different than what is being tested with I figured I'd mention it.

[Stark-X]

May I know when would this fix be released?

[asimell]

I will probably make the release today, unless I find any other bugs that should be fixed immediately as well.

[kumbasar]

@asimell could you please wait this week? I also want to open another merge request for another log read issue.

[asimell]

@kumbasar Definitely. This is exactly why I said "unless I find any other bugs" 😁 It just so very often happens that immediately when I make a release "in a rush" I overlook something and then I need to make another release the very next day (just like what happened with 3.1 and now 3.1.1).

[cburne-oshyn]

Hey guys, I just updated my plugin and I'm getting an issue that is resulting in no data being sent to influx. I use on-prem sonarqube, not cloud version but as I read the code that shouldn't be an issue. I reproduced the buildTask, issueUrl and metricUrls as they show in the SonarQubePointGenerator.java code and executed them using curl with my token and they result in regular JSON as expected so I'm not sure what the issue could be. @kumbasar's logic for parsing the build log works b/c it's getting the task ID out successfully and the analysis url properly (see screenshot). I'm not able to figure out which http request is resulting in HTML being sent back to me instead of JSON being sent back to me. Any assistance would be greatly appreciated. I have multiple customers that are looking for this data and it hasn't been available for a bit.

[kumbasar]

@cburne-oshyn we are also using an on-prem sonarqube. Could you please share your Sonarqube version? AFAIK, we are using the LTS one v8.9 LT and we are not facing with this issue.

[cburne-oshyn]

Version 9.3 (build 51899)

I do not have any quality gates. I see that as a difference too, but I executed the metric URLs for the quality gates from curl and they were successful.

[cburne-oshyn]

I can troubleshoot this if I can compile my own version of the plugin but I haven't developed in Java for over a decade. Could you maybe point me in the right direction as to which IDE the project is setup for and any plugins required for me to compile into the jenkins plugin so I can debug my issue?

[kumbasar]

I just use VS code. Also, you can check out Jenkins’s Developer Guide

[cburne-oshyn]

Okay, I see the issue. My log message looks like this:
INFO: ANALYSIS SUCCESSFUL, you can browse https://sonarqube.xxx.com/dashboard?id=XXX.Web

So the URL that is constructed by the plugin is:
https://sonarqube.xxx.com/dashboard?id=XXX.Web/api/issues/search?ps=1&componentKeys=XXX.Web&resolved=false&severities=CRITICAL

when it should be:
https://sonarqube.xxx.com/api/issues/search?ps=1&componentKeys=XXX.Web&resolved=false&severities=CRITICAL

without the "dashboard?id=XXX.Web" in it.

I will fix it but I'm curious how this works for you. Does your "ANALYSIS SUCCESSFUL" line not have the "dashboard?id..." in it? Maybe the newer version of sonarqube returns a different URL to the scanner.

[cburne-oshyn]

Okay, @kumbasar , I added a new PR here: #131

It works for my sonarqube, but could you check to see if it works for yours? I am stumped why my ANALYSIS SUCCESSFUL url is different than yours. I am using version 5.4.0.40033 of the SonarScanner for MSBuild in case that is a difference as well.

[cburne-oshyn]

@kumbasar @asimell - the real fix should be to make the findReportByFileName() method work across multiple jenkins agents as I suspect that is the issue with the getSonarProjectFromBuildReport() method. However, I do not know how to do a File.find() that works across agents, especially Kubernetes nodes and I wasn't able to come up with anything in a quick google search this morning.

[asimell]

@cburne-oshyn I believe the root cause for your issue is one of the following:

1. You are not exposing SonarQube env variables, so the plugin cannot access SONAR_HOST_URL env variable to get the build URL
2. You are not using withSonarEnv() wrapper around your InfluxDbPublisher step in your pipeline to make the plugin aware of the SonarQube environment variables
3. Your report-task.txt generated by SonarQube has the /dashboard=... in it, so it's not looking the at build logs, but rather the report file, to which support was added in plugin version 3.1.

Whatever the cause is, you could try setting SONAR_HOST_URL variable before calling InfluxDbPublisher. However, I'll take a look at your PR. It didn't look very complex and I could merge it, but I just want to make sure my deduction of the root cause is actually accurate.

[cburne-oshyn]

@asimell , I confirmed the code as is will only work if the job is running on the jenkins controller node. I did this by building the directory structure and creating a report-task.txt with junk data in the controller and the logic picked it up as expected. The two paths forward I can see are:

1. change the SonarQubePointGenerator.findReportByFileName() method so it works on agent or controller depending on where the job is running
2. force people to stash the directory and unstash on the controller before calling the plugin

For #1, I've been searching for a few days and I can't find anywhere that people have written java code in a plugin that accesses the file system that works when build is running on agents. The groovy methods for findFiles() does this so I will investigate the source for that and try that logic.

This is my first time looking at Jenkins plugins so it's entirely possible I'm wrong here but it's what the current evidence points me to.