How do you provision projects: from the UI or on first analysis?

Clean Code Discussions
1

What’s your preferred method of putting new projects under analysis?

Do you want to walk through the UI wizard each time, or be hands-off with scripting or automatic project creation on first analysis?

And would you characterize your organization as large or small? (Note that I’m deliberately not providing numbers for these characterizations. It’s what you think your org is. :smiley:)

5

I don’t create any project manually - in some companies I worked for this wouldn’t have been feasible with the amount of projects. For me it’s 100 % automatic project creation on first analysis.
That is why the permission template feature is awesome and I’m still eagerly waiting for the option to define a default regular expression to detect long living branches for an entire SonarCloud organization ;).

The SonarCloud organization of my current company is small though.

3 Likes
6

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.

4 Likes
9

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.

11

Thanks for the insight, everyone. It’s good to have confirmation that the default in large organizations is still creation-on-first analysis.

Internally we create new projects so infrequently that I have to remind the devs sometimes that automatic creation is still important for a lot of people!

1 Like
12

We are a medium sized organisation I would say.

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 :confused:
  • 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”

1 Like