Says there is a turial we have not been able to find anywhere. We did follow the very basic info page you get when you click on “analyse project”, but this only shows you how to run it once locally.
The docs then say “From now on, a new analysis will be triggered every time you make a change to the main branch by direct push, pull request merge, or branch merge”
How can this possibly happen? How does one set this up? We understand we can setup a pipeline to run the maven command, but when? On push? if so it will only get pushes, not merges. If we do it on push, will it analyse only the pushed code, or all the code? If it only analysis the pushed code, How do we analyse all the code? ITs completely unclear, Sonary really need a tutorial or proper documentation as we are just guessing how it works.
# Viewing your first analysis' results
If you have successfully followed the in-product tutorial, SonarQube Cloud will run its first analysis on your project.
The first analysis is always a *main branch analysis* (an analysis of the default branch of your repository, usually called `main` or `master`).
From now on, a new analysis will be triggered every time you make a change to the main branch by direct push, pull request merge, or branch merge.
Where is this tutorial mentioned above, and how can it possibly trigger every time the brach changes when we have only run it once locally (via maven), as per the instructions when we click “alayse now” in the sonar ui.
As I responded in your previous thread, 2 weeks ago:
Note that I did not give you a more specific starting point because AFAICT, in none of your threads have you mentioned what CI you’re using.
But the general idea is that you have a pipeline configured for each project. And in each pipeline, you automatically run the build after a commit, right? So you would simply add analysis to those pipelines so that when they’re triggered for commits, analysis becomes part of what runs automatically.
we use maven. We haven’t setup a pipeline yet as first we need to be able to get it working locally.
When you click on “configure analysis” the first time, it gives you a page where you select the tool (maven in our case), then gives you a page with single command, a env var to set and 2 lines to add to pom.
Is this considered a tutorial?
We assumed a tutorial would take us right though the steps of getting it to pickup PRs and branches, gates, editing profiles etc.
Also, once you have run it once, it doesn’t seem possible to get to this page again.
Also, the “tutorial” says this:
If everything is running successfully, once the analysis is complete you'll be redirected to the Overview page of your project where the new analysis results will be displayed. This can take a few minutes.
* Each new push on the main branch triggers an analysis by SonarQube Cloud.
* Check the [Pull Request Analysis](https://docs.sonarsource.com/sonarqube-cloud/improving/pull-request-analysis/) documentation to trigger analysis on each push on any branch.
But this simply doesnt work. you get the initial results, but each new push to main branch does not trigger an anaysis by sonarqube. If we do the analyasis manually (by pushing a new branch, creating a PR, then running the analysis on the PR branch), nothing happens - there are no new branches or PRs in the UI.
Also, its got the wrong main branch, we want it to use develop, but it seems to be using master. By the time it gets to master its basically deployed to production, so is to late.
Ehm… This is the basis of some of your struggles. Nothing in SonarQube Cloud tutorials, wizards or docs anticipates manual analysis.
The idea is that you get the analysis instructions from the wizard, you insert them into your pipeline, and… you’re done.
And because your pipeline runs automatically for both branches and PRs, then once your pipeline includes analysis, analysis happens for all the things!
Nope. Because once you’ve added the analysis command to your pipeline, you don’t need that page again. You just need the analysis results.
SonarQube Cloud does not run analysis (unless you’re using automatic analysis, and even then, SonarQube Cloud itself doesn’t run analysis, it triggers a CI for you in the background.)
Somebody, somewhere has to set up a CI to
notice that the code has been changed
check out the code
build the code
run analysis
[update the pipeline with the Qualtiy Gate results]
We try to keep it to one topic per thread. Otherwise it can get messy, fast. And since you’ve resurrected another thread with this issue, we’ll set it aside here.
We want to run it in a a pipeline. We can easily setup our CI to do any commands we need. We need to know what those commands are. The only command the “tutorial” tells us under “with other CI tools” is:
It looks like this is not enough info to setup a pipeline. If we cant run it locally (and pickup PRs), we certainly cant put it into a pipeline unfortunately.
What we need is someone to tell us what we need to do to run analyse, then we can automate it.
The above command fails because it thinks master is the main branch. We NEVER want to test PRs against main branch, they must be tested against develop or possibly staging in order to catch problems as soon as the PR is submitted by the developer, not when we deploy to prod…
In your example:
notice that the code has been changed
check out the code
build the code
run analysis
[update the pipeline with the Qualtiy Gate results]
We know how to do all of these EXCEPT 4 and 5, as they require information from sonarcloud we are having problems finding.
Also, because we hit the “configure analysis” once, and used the maven commands, there is no way to go back to it to find the other options to configure other methods.
We dont use bitbucket pipeines, circleci nor azure pipelines, so we need to know what to run in our own CI for steps 4 and 5, and these are not given to us in the tutorial unfortunately.
I think you’d be surprised. In fact, we’ve crafted the integrations with the popular CIs to automatically detect branch and PR information from the environment and insert it into analysis. You’re trying to make this much harder than it has to be.
create a new PR branched called feature/xxx from the staging branch.
push it back to bitbucket.
Create a PR in bitbucket.
checkout the PR branch
run the required maven command
The result is that there are no PRs in the UI, no branches other than main-master.
Please help us understand what steps we are missing?
We assume this is because sonar is configured to only look for PRs against the master branch, even though we nave never run it on the master branch, we only ever analyze on staging or PRs from staging
NOTE: Whether we run the above in a pipeline or locally is the same steps. If we can do one we can do the other. A pipline is nothing more than automation of what we could do locally. If we cant do it locally, we cant automate it. running it locally exactly as instructed doesn’t pickup any PRs.
the long lived branches pattern in the top right already says Long-lived branches pattern:(branch|staging|feature)-.*
There is no edit button to edit the branch patter. We can send a ticket to the organisation admins, but we would need to know exactly what to change it to. What should it be?
how do we delete staging?
How do we re-create it?
If we run the pipeline “without passing a branch name parameter” then this wont work - it completely ignores our staging branch and any PRS created on it.
How will it be created as main? We have only ever run the analyse command on the staging branch or a PR of it, and it took from that the main branch was master. Unless we do something different to change it, we wont get staging as the main branch
This is a regex describing which branch names should be recognized as the names of long-lived branches. I can’t answer this for you. How are your long-lived branches named?
This question of yours has been asked and answered in a different thread.
Are you trying to say that analysis isn’t performed if you don’t pass a branch name parameter? I sincerely doubt that.
Without a branch name, it will be analyzed as the project’s main branch. A project admin can then rename the branch to whatever you like from the row menu on the branches page. From there, analyzing with the correct branch name - which will be passed automatically from your environment once you finally set up CI analysis - should work perfectly.