Issues/commit reported on the wrong branch

SonarQube Cloud
1

  • ALM used : GitHub

  • CI system used : Github actions

  • Languages of the repository : java

  • Error observed

  • We activated SonarCloud on our github repository some months ago
  • We have our main branch (called main, where we merge PR from feature branches
  • We have maintenance branch (called 2023.1.x, 2023.2.x, …) where we backport some bugfixes (cherry pick of commit from main to the maintenance branch)

Sonar detected our main banch as Long-lived and the maintenance branch as Short-lived
We do not really care as we only monitor quality gate from main branch

Until now everything was fine but today someone used a PR to backport a bug in 2023.1 (instead of direct cherry picking), and it seems it messed up sonar analysis. Now we have old bugs/vulnerabilities from 2023.1 branch reported in main (things we already fixed in main, so the report is not relevant anymore) .

image
image1290×328 13.8 KB

commit c022f104 is a commit in 2023.1.X, not in main:
image

What could have caused this ? is sonar expecting PR to be merge only in main branch ? how can we avoid this issue ?

2

Hey there.

Can you share how your GitHub Actions are configured (the YAML file)?

3

Hi Colin

Here the parts related to Sonar

on:
  workflow_dispatch:
  push:
    branches:
      - main
      - 2023.1.x
....
      - name: Cache SonarCloud packages
        uses: actions/cache@v3
        with:
          path: ~/.sonar/cache
          key: ${{ runner.os }}-sonar
          restore-keys: ${{ runner.os }}-sonar
............
          releng/mvnw clean deploy -f releng/com.semarchy.xdi.runtime/pom.xml \
            -Psemarchy,xdi.deploy,coverage \
            org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=semarchy_xdi-runtime \
            -Dsonar.coverage.jacoco.xmlReportPaths=${{ github.workspace }}/releng/com.semarchy.xdi.runtime/coverage-aggregate-runtime/target/site/jacoco-aggregate/jacoco.xml \
            -Dxdi.ci.nexus.deployment.url=${{ env.NEXUS_CI_URL }} \
            -Dbranding.product.version=${{ env.BRANDING_VERSION }} \
            -Dmaven.test.failure.ignore=true
......

Since we have PR pushed in main, report comes back to normal but we may have the issue back if someone merge a PR in 2023 branch. You can see in evolution strange things:

image
image724×256 11.8 KB

4

Hey there.

I see two things that could be happening:

  • I wonder if more is getting merged into your your main branch when doing the PR from your maintenance branch than you expect
  • Otherwise, somehow the GitHub action being executed on your maintenance branch and sonar.branch.name is being defaulted to main.

Can you provide the logs from a GitHub Actions run where the wrong commit is analyzed as being on the main branch in SonarCloud? I can open a private message channel if needed.

5

Unfortunately I lost access to logs of last github action where we faced this (PR on maintenance are not so frequent), they purge logs.
Just to clarify we do not merge PR from maintenance into main, it is the opposite, we always commit in main, then cherry pick commits directly in maintenance branch, except in case of conflicts, where we create a work branch from maintenance branch, cherry pick the commit in work branch, resolve conflicts and open PR from work branch to merge it into maintenance branch (this is this particular workflow which seems to cause the issue)

6

As soon as you have another PR with this issue, please save the logs and provide them here or via a private message! That will be the best way to understand what’s going on.

7

Hello, Colin
I just did a trivial direct commit without PR on the maintenance branch. No action was launch from this commit, but still sonar, failed our quality gate on main with scan result from the maintenance branch instead.
I have no log as no github action runs

image
image1275×381 34.7 KB

image
image787×520 22.4 KB

8

the next commit in main, while not related restored the quality gate

image
image811×544 27 KB

9

That’s odd.

Is your project configured to use Automatic Analysis (Project Administration > Analysis Method)?

10

I do not see the way sonar consider it configured, but I followed instructions With Github Actions

image
image1302×516 29.7 KB

11

You don’t see this?

Screenshot 2023-07-05 at 18.19.32
Screenshot 2023-07-05 at 18.19.321796×546 49.3 KB

12

No, for me Project Administration > Analysis Method looks like more a “documentation page”, than a “configuration page”

13

Is your project bound to your GitHub repo?

14

Yes sonarcloud indicates “This project is bound to github”

15

I’ll reach out to you privately for your project key.