SonarQubeTM portal

Table of Contents

  1. Manage the permissions on your project
  2. Add a user to your project
  3. Personal token sharing
  4. Manage users using Inria LDAP groups
  5. Login with Gitlab
  6. Integration with Gitlab
  7. Change the activated rules

Manage the permissions on your project

When a project is created the default permissions are the following:

  • it is private so that non authenticated visitors will not be able to see the project in the dashboard
  • authenticated users can see the project in the dashboard, explore the metrics, but can't see the source code
  • the user who has created the project through its first analysis becomes the administrator

We have chosen to let authenticated users see the project in the dashboard and explore metrics in order to show to the Inria community that developers follow good practices. We expect il will motivate users to do their best.

Of course the administrators of a project can always change this default behaviour in the Administration, Permissions panel of their project. For instance, one can remove the ability to any authenticated user to browse the project metrics. To do so, just uncheck Browse for sonar-users.

The project can also be made public to let any visitor see metrics and the source code, see the Administration, Permissions panel.

Add a user to your project

A project administer can add a user to a project. In the project page, go to the Administration tab then choose the Permissions section. Then search a user and specify the project-level permissions. Remember that only Inria members who have once connected to the SonarQubeTM plateform will be visible.

Personal token sharing

The personal token is used to authenticate to the SonarQubeTM server when a user wants to publish analysis results.

Recall the procedure to create a token:

  • when logged in, go to "My account" (top right)
  • select the Security tab
  • generate a token
  • copy the generated token (a 40 letters key) and store it

This token will be useful to authenticate to the instance replacing authentication with the login/password pair. It will be used for example as a secret variable on Gitlab or Jenkins, or directly stored on the machine performing analysis and tests (e.g. virtual machine).

Notice the token is per user, not per project. It is not supposed to be publicly available. Of course to automatize analysis in a CI (continuous integration) process one token will be used on some machines shared by administrators of the CI. It means you trust your collaborators of the CI project. As soon as you leave the project or if you don't trust your collaborators anymore you should revoke the personal token you used for this project. An advice: an Inria permanent member should create the personal token to avoid updating the token too often. In addition, one personal token per project should be created so that one can revoke a token related to a specific project without loosing the permission to publish reports on other projects.

This personal token sharing seems to be a weakness since several people can publish results in the name of one user. This is true. But it is the way SonarQubeTM works... A solution could be to create some additional SonarQubeTM accounts, one per project, to create non personal tokens. We don't want to come to that because:

  1. this is a lot of additional administrative tasks (creation/destruction of fake accounts),

  2. this solution just shift the problem. Several people may have access to the project's SonarQubeTM account and add/revoke tokens so that the authenticity problem remains the same.

Manage users using Inria LDAP groups

Existing Inria LDAP groups can be used to handle users more easily on several projects, see Group synchronization. To do so, one need to create an Helpdesk ticket (email to the support) and ask for the creation of the SonarQubeTM group giving its name (it must already exist in LDAP).

Login with Gitlab

Users that already have an account on https://gitlab.inria.fr can use their gitlab's login and password to authenticate on https://sonarqube.inria.fr/sonarqube. It will create a new SonarSube's account at first login.

For those who already had an account (LDAP login) you can send an email to the support to ask for the change to gitlab's authentication. In the email you have to give your Gitlab User ID (on your profile page in user settings) so that we can convert the account for example like this (e.g. Gitlab user ID is 97):

curl -u admin:${TOKEN} -X POST "https://sonarqube.inria.fr/sonarqube/api/users/update_identity_provider?login=jdoe&newExternalIdentity=97&newExternalProvider=gitlab"

Integration with Gitlab

The sonar-scanner program in gitlab-ci pipelines can automatically detect push branch and merge request events and make the job to fail if the quality gate fails. It can also add comments in merge requests on new lines of code affected by issues. See documentation.

Change the activated rules

To enable/disable the rules watched during analysis a new Quality profile can be created and modified to match the software requirements, see the documentation.

The Quality gates can also be created and modified, do not hesitate to ask the support.

© Florent Pruvost, Hervé Mathieu 2016

Powered by Pelican