When using Structure101 Build with SonarQube the detection of new structural issues can be delegated to SonarQube. This simplifies the configuration of Structure101 Build but requires an appropriate SonarQube Quality Gate to be defined.
- Packages should not be Fat
- Classes should not be Fat
- Methods should not be Fat
- Packages should not contain tangled sub-packages
- Dependencies should comply with the Structure Spec
- Items should not exist in a specified scope unless they are included in the Structure Spec
- Dependencies should comply with all enforced Architecture Diagrams
Installing and Configuring the SonarQube Plugin
The Structure101 SonarQube plugin jar file should be copied into the extensions/plugins folder of the SonarQube installation. Any previous version of the Structure101 plugin should be removed and the SonarQube instance restarted.
Create a new Quality Profile with language Java
Change the parent to your existing Java quality profile
Click Activate More to add the Structure101 rules
Filter the rules using Java language and Structure101 repository
Activate each of the rules setting the desired severity
Configuring the Quality Gate
On the SonarQube Quality Gates tab click Create and enter a suitable name in the dialog
For this example the rules were added with a severity of critical and the build will be failed if any new critical issues are detected.
Click Add Condition and select New Critical issues. Set the parameters appropriately.
Configuring the Build
It is assumed that SonarQube is already setup for your project
Structure101 Build must run the report-key-measures operation before the SonarQube scanner executes
The SonarQube scanner must have the system property structure101.reportdir set so that the Structure101 SonarQube plugin can find the output file of the report-key-measures operation
Your Studio project file containing Structure Spec, Architecture Diagrams and Action Lists should be committed to source control so that it is available to your CI process
When multiple branches are published with the same Structure101 Repository Project name then the report-key-measures operation must be configured to use the local Structure Spec and Architecture Diagrams. (ie those contained in the .hsp file)
This ensures the checks are against the correct spec and diagrams for the branch being built. (The latest repository snapshot cannot be used because it may be for a different branch)
Set these properties – useProjectFileSpec=true and useProjectFileDiagrams=true
(Using the local project diagrams is good practice anyway as it removes the need to manually publish updated diagrams or Action Lists. The hsp file can be updated in Structure101 Studio and committed to source control. The next CI build will then publish the updates to the Repository)
This is an example pom.xml configuration to execute the report-key-measures goal
<plugin> <groupId>com.structure101.java</groupId> <artifactId>maven-structure101-plugin</artifactId> <version>14507</version> <configuration> <project>maven</project> <localProject>structure101-settings.java.hsp</localProject> <repository>http://ubuntu-server:8989/s101j/data</repository> </configuration> <executions> <execution> <id>s101checkKeyMeasures</id> <phase>compile</phase> <goals> <goal>report-key-measures</goal> </goals> <configuration> <report-key-measures-output-file>target/s101-results/key-measures.xml</report-key-measures-output-file> <use-project-file-spec>true</use-project-file-spec> <use-project-file-diagrams>true</use-project-file-diagrams> </configuration> </execution>
The report-key-measures-output-file path must be passed to the SonarQube scanner in the system property structure101.reportdir
For example, mvn sonar:sonar -Dstructure101.reportdir=target/structure101-reports/key-measures.xml
Or in the Jenkins build step as shown below