SonarQube Analysis going to Main branch instead of the correct branch

Sonarqube version: 10.1 (build 73491)
What are you trying to achieve: Trying to apply a hotfix to a branch named 2209RTM and not the main branch.
What have you tried so far to achieve this: Currently we have these arguments in the pipeline:
trigger:
batch: true
branches:
include:
- 2209RTM

The pipeline correctly shows the execution branch but in SonarQube the newest analysis is going to the Main branch.

Hi,

You haven’t provided a lot of detail here. What’s your CI system? Can you share your analysis log?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

 
Ann

Could you PM me and I share the logs that way?

Hi,

Feel free to redact as necessary.

 
Ann

We are using Azure DevOps.
Let me know if this isn’t the correct log.

Analysis Log.txt (1.3 MB)

Hi,

Can I also have the log for the begin step?

 
Ann

Where would that be found at?

Hi,

I’m not familiar enough with Azure DevOps to tell you exactly where to look, but it’s the logs for the step before the build.

 
Ann

They gave me this and said this is the full log of the job all they way through the end. Let me know if this works. Thanks.

SQLog.txt (28.1 MB)

Hi,

Thanks for the log.

I was looking first to see if you were specifying the branch parameter in the start command. You’re not, so then I went back to the docs, to double-check how this is supposed to be working.

In an Azure DevOps pipeline, the scanner should be reading any branch or PR parameters from the environment.

The fact that that’s not happening, made me back up to your checkout (yay for the full job log!).

From your log, it looks like you’re checking out a reference / commit hash, rather than a branch.

2023-07-25T17:02:24.3747929Z  * [new ref]             5af063757e8e296ecb6434b7d1630d50a17310f1 -> origin/5af063757e8e296ecb6434b7d1630d50a17310f1
2023-07-25T17:02:24.6989764Z ##[command]git checkout --progress --force 5af063757e8e296ecb6434b7d1630d50a17310f1

Which would explain why analysis doesn’t detect that it’s on a branch and provide the necessary analysis parameter.

Does that make sense?

 
Ann

Yes that makes sense. So, what exactly needs to be changed/removed and added for it to be correct?

Hi,

You need to check out a branch, instead of a revision.

 
HTH,
Ann

This is the response from my team with pictures:

The actual checkout isn’t to a commit, it’s a branch. The specific commit line that they reference is just the last commit to that particular branch, but I am not fetching based on that commit. As you can see above, the Checkout that AZDO knows it’s doing is the 2209RTM branch. I am not issuing against a specific commit. I have even gone into Pipelines, edit, selected the branch, then done RUN from there so that everything defaults to 2209RTM, but looking at the log shows that same commit. That is the last commit done to the branch, so it makes sense that it would force to the latest.

Please ask them to see if there is something specific we can set.

I just pulled up the last log I had where the SQ run went as the proper branch, and it showed exactly what I expected – the forced checkout is the commit at that point in time

That being the case, why did it work then and not now?? And why are the OnCall runs all showing under main instead of the individual release/maintenance branches?

Hi,

It looks like these screenshots are from the log you provided above?

I believe the highlight in your first screenshot is simply a comment. After the automatically-added timestamp, the actual output starts with #, which is what marks a comment line.

And then the second screenshot is basically what I excerpted, plus a little more. You’ve got the line about [new ref], and then the line checking out that ref. The thing is, a ref is a pointer to a commit. Not to a branch. Maybe the commit is in a branch…? But what’s being checked out is a commit. Not a branch.

 
HTH,
Ann

So someone else on a team had a suggestion that worked and it was to add sonar.branch.name=$(Build.SourceBranchName) to the parameters and that seemed to fix the issue.

Thank you for the help though!