Status: To Do
Obviously if you carefully think about your branch management in the SCM you can set the proper main branch upfront by analyzing that branch first without the sonar.branch.name property.
a) However many customer do and will:
- Originally analyze the main branch as the master
- Finally discover all the consequences of the main branch after some time of historical analysis
- Main branch is the one displayed by default in project home page
- Main branch is the branch used in portfolios and applications
- Global issues page only considers issues of the main branch
Once they discover this, it’s too late to change the main branch and preserve the history of everything that has been analyzed so far.
b) A 2nd use case is that, for long lasting projects, the development practices may evolve and SonarQube should be able to follow this evolution. For instance, a project that would start with all development on the master branch and that would at some point switch to the GitFlow model where all the development is on the develop branch.
Allowing this change has implications for Applications and portfolios:
- master is analyzed as Main branch of project Foo
- Foo (master) is added to portfolio P
- Foo (master) is added to application App
- Foo's dev is analyzed as a long-term branch
- App branch a_br is created, pointing to Foo's dev branch
- Foo is updated to make dev the Main branch
- definition of P is silently updated & P is recalculated
- Portfolio values swing wildly
- definition of A is silently updated & A is recalculated
- Application values swing wildly
- App now has both its master and a_br using to dev
I think these consequences are acceptable if properly documented, and warnings are added to the UI.