I’d rather prefer creating projects with all required configuration as code. The problem with the automatic project creation is it does not set all the configuration needed, like GitHub PR decoration (as far as I know). Creating project from the UI also requires modifying the project key. If you are building a Maven project, for example, where it derives the project key from the group ID and artifact ID, you must update the project in SonarQube accordingly.
The projects YAML build pipelines in Azure DevOps are in general created in a branch and merged to main with an pull request. There is no manual interaction in SonarQube done to create the project in our group, the internals at 10 locations in 3 countries and some external co-workers.
Besides SonarQube updates there are rarely the need to fine-tune our own rule set for some projects, especially legacy projects.
Personally, I prefer to keep the uniform quality gate for all locations, even if there are some colleagues who then put a lot of pragmas in their files to suppress the rules. These are the same, who disable auto-format.
As we defined our own ruleset and wanted to disable some rules of SonaeWay, I would like to have the possibility to inherit from your reuleset and disable rules.
And with 9.9 I saw the box that indicate our quality gate doesn’t fullfil completely SonarQube’s definition for clean code.I would like to accept this information and don’t see it again.
In the move towards configuration-as-code, we would definitely prefer to be able to configure via the API, using terraform.
This is not really possible for several reasons:
Not everything is exposed via the public API
Even if it is, it can be very hard to find
Some properties of the project can only be set/changed at analysis time - e.g. the “well known” links, project description/name and others - when really these should be considered “project level”, especially where they only get applied in a master branch analysis so are not per-branch.
It is impossible to configure new code analysis without a branch existing to configure
There is no facility to configure rules for new branch patterns.
To expand on the latter two, we do this:
Code in production is in the “prod” branch, latest code is in “master” => code is “new” with respect to “prod” - this means the prod branch has to exist before we can configure that rule…which it won’t do for a new project until it actually gets to prod.
This means we have to configure the SQ project with some interim setting (compare to previous version) temporarily then later, when we get to prod, configure prod to compare to previous version and master to compare to prod.
New features are developed in feature/ticket branches => code is “new” with respect to master
Candidate releases are cut from master and named release/version => code is “new” with respect to prod.
Fixes to releases are developed in relfix/ticket branches => code is “new” with respect to the base release/version branch
Fixes to production are developed in hotfix/ticket branches => code is “new” with respect to “prod”
The above means we have to figure out the sonar.newCode.referenceBranch at build time and apply that to the analysis rather than being able to define patterns on e.g. release/* or hotfix/*
Also, our branching for components we develop (nuget, pypi etc) vs applications is a little different, less complex so we need to know at the time the SonarQube project is being created what type of project is being analysed so we can set the new code comparisons as appropriate - it would be nice to be able to have project templates so we could, via the API, say “create a project using this template”