We use SonarCloud - Github with Github Actions.
Our repository is a monorepo : PHP , Laravel , JS .
We have two branches:
release
production
We disabled automatic analysis and started to use GitHub Action to be able to have another Long-lived branch which is production in our case.
Firstly, we pushed the build.yml file including test coverage steps to .github/workflows/build.yml. It worked but then we removed the test coverage steps and updated the file again as below.
Now, we don’t understand the three points below:
Why do we still have code coverage analysis?
Why do we not have sonarcloud analysis for production branch? Do we need to have at least a PR from the production branch?
SonarCloud started to miss some PRs. It began after we disabled automatic analysis and started to use GitHub Action.
name: build SC
on:
push:
branches:
- release # The default branch
- production-* # The other branches to be analyzed
pull_request:
branches:
- release # The default branch
- production-*
types: [opened, synchronize, reopened]
jobs:
sonarcloud:
name: SonarCloud
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SonarCloud assumes that if you’re using CI-Based Analysis, you want to provide coverage information. You can turn this off by excluding all files from coverage.
Probably your GitHub Action isn’t running on the production branch or branches targeting it. Looking at the GitHub Actions YAML file, it wouldn’t trigger on a branch named production, only production-something.
The first issue below is resolved.
For the third issue, I need to gather more information, so I keep working on it.
For the second issue, after I made your suggestion and push the files to production branch as well, I get production branch on SonarCloud. However, it is listed under short-lived branches. How can I make it long-lived branch?
You’ll need to delete the branch and adjust the long-lived branches pattern before triggering a new analysis of the production branch… A project-administrator can take all of these actions from the project-level Branches page.
So, I should follow the steps below, respectively:
Delete the branch
Adjust the long-lived branches pattern
My other long-lived branch is production. So the pattern should be (branch|release) instead of (branch|release)-.*.
Your pattern will have to match the word production exactly – so perhaps production|((branch|release)-.*) or just (production|release) if those are the only two branch names you expect.