Create a redline test step with SonarQube-Alibaba Cloud DevOps(Alibaba Cloud DevOps)-阿里云帮助中心

Why create a redline test step?

Ensure core function stability: The redline feature targets the most critical functions of your system. Dedicated test steps for these functions ensure they remain stable after code changes.
Get fast feedback on issues: If a redline test in the pipeline fails, your team can quickly identify and fix major defects on the critical path, preventing the release of unstable versions.
Raise quality standards: A clear redline definition encourages developers to submit code carefully, ensuring that important business logic is fully verified and improving overall software quality.
Reduce long-term costs: Finding and fixing redline issues early in the development cycle is more cost-effective than addressing them in production, saving on maintenance and support costs.
Build confidence: After successfully passing a CI/CD process that includes redline tests, your team will have greater confidence in the upcoming release, knowing that the most critical parts are working as expected.

In short, adding a test step with the redline feature to your pipeline helps maintain core application performance and encourages efficient, high-quality development.

Prerequisites

A publicly accessible SonarQube service.

A code repository for testing. This tutorial uses a Maven project as an example. Ensure the SonarQube plugin is included in your pom file:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.sonarsource.scanner.maven</groupId>
                <artifactId>sonar-maven-plugin</artifactId>
                <version>3.4.0.905</version>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

Local development

Set up your development environment by following the instructions in Flow CLI subcommand: step, then initialize a step:

flow step init sonar-qube

Three files are created in the sonar-qube directory:

Dockerfile builds the step image. Alibaba Cloud DevOps provides the base image, which includes the necessary software. Avoid changing the base image. If you must change it, ensure that jq is installed in the new base image.
step.sh is the script that runs within the step.
step.yaml describes the step's metadata and configuration.

Frontend

Edit the step.yaml file in the sonar-qube folder:

---
name: SonarQube (Staging)
sign: sonar-qube-staging
description: Use SonarQube to test public steps
category: Static Scan
image: registry.cn-beijing.aliyuncs.com/build-steps/sonar-qube-staging:1.0
items:
  - label: Sonar Server Address
    name: STEP_SONAR_HOST
    type: input
  - label: Redline Information
    name: CHECK_REDLINES
    type: addable_group
    rules:
      - require: false
    add_button:
      type: icon
      icon: plus
      text: Add Redline
      tip:
        icon: question-circle
        description: The step fails if the redline check fails. 
    template:
      items:
        - name: redline
          label: Redline
          position: flat
          type: custom_redline_dropdown
          datamap: '[{"key": "Bugs","type": "LE"},{"key": "Vulnerabilities","type": "LE"},{"key": "Smells","type": "LE"},{"key": "Coverage","type": "GE"}]'
          rules:
            - require: false

Parameter	Description
name	The name of the step.
sign	The unique identifier for the step. It must be globally unique.
category	The category of the step.
image	The address of the step image. Set `image` to your own image address and ensure it has public pull permissions.
items	Defines the UI for the step's parameters. For more information, see the step language YAML reference.
redline	Redline information.
datamap	Valid values for `type`: `LE`: The actual value is less than or equal to the threshold. `GE`: The actual value is greater than or equal to the threshold. `EQ`: The actual value is equal to the threshold. The `key` specifies the field to validate.

The following keys map to predefined UI labels. Custom keys are displayed as written.

Key (case-insensitive)	UI label
passedrate	Test pass rate
total	Total issues
blocker	Blocker issues
high	High issues
medium	Medium issues
critical	Critical issues
major	Major issues
violation	Violation issues
information	Information issues
warning	Warning issues
error	Error issues
linecoveragerate	Line coverage rate
branchcoveragerate	Branch coverage rate
methodcoveragerate	Method coverage rate
classcoveragerate	Class coverage rate
instructioncoveragerate	Instruction coverage rate

Validate the YAML file. In the sonar-qube directory, run the following command:
```
flow step valid
```
No output indicates that the validation was successful.

Backend

Edit the Dockerfile:

FROM registry.cn-beijing.aliyuncs.com/rdc-builds/oracle-jdk:1.8
MAINTAINER jintang <yidong.***@alibaba-inc.com>
COPY .step/*.sh /root/
COPY sonar-qube/step.sh /root/step.sh
RUN chmod +x /root/*.sh
ENTRYPOINT [ "/root/entry.sh"]

Ensure that jq is installed in the base image.

Edit the step.sh file in the sonar-qube folder:

#!/bin/bash
set -e
export SONAR_INFO=$WORK_SPACE/sonar_info.json
# System-provided parameters from the pipeline context
echo [INFO] PIPELINE_ID=$PIPELINE_ID       # Pipeline ID
echo [INFO] PIPELINE_NAME=$PIPELINE_NAME   # Pipeline name
echo [INFO] BUILD_NUMBER=$BUILD_NUMBER     # Pipeline run instance number
echo [INFO] EMPLOYEE_ID=$EMPLOYEE_ID       # ID of the user who triggered the pipeline
echo [INFO] WORK_SPACE=$WORK_SPACE         # Directory in the container (/root/workspace)
echo [INFO] PROJECT_DIR=$PROJECT_DIR       # Root path of the code repository (default: /root/workspace/code)
echo [INFO] PLUGIN_DIR=$PLUGIN_DIR         # Plugin path (default: /root/workspace/plugins)
echo [INFO] BUILD_JOB_ID=$BUILD_JOB_ID     # build-service task ID
cd $PROJECT_DIR
mvn install -DskipTests
mvn sonar:sonar -Dsonar.host.url=$STEP_SONAR_HOST
STEP_PROJECT_GROUP_ID=`mvn -q -Dexec.executable=echo -Dexec.args='${project.groupId}' --non-recursive exec:exec 2>/dev/null`
STEP_PROJECT_ARTIFACT_ID=`mvn -q -Dexec.executable=echo -Dexec.args='${project.artifactId}' --non-recursive exec:exec 2>/dev/null`
curl $STEP_SONAR_HOST/api/measures/search\?projectKeys\=$STEP_PROJECT_GROUP_ID%3A$STEP_PROJECT_ARTIFACT_ID\&metricKeys\=alert_status%2Cbugs%2Creliability_rating%2Cvulnerabilities%2Csecurity_rating%2Ccode_smells%2Csqale_rating%2Cduplicated_lines_density%2Ccoverage%2Cncloc%2Cncloc_language_distribution > $SONAR_INFO
STEP_SONAR_BUGS=`jq -r '.measures[] | select(.metric == "bugs") | .value' $SONAR_INFO`
STEP_SONAR_VULNERABILITIES=`jq -r '.measures[] | select(.metric == "vulnerabilities") | .value' $SONAR_INFO`
STEP_SONAR_SMELLS=`jq -r '.measures[] | select(.metric == "code_smells") | .value' $SONAR_INFO`
STEP_SONAR_COVERAGE=`jq -r '.measures[] | select(.metric == "coverage") | .value' $SONAR_INFO`
redline Bugs:Bugs:$STEP_SONAR_BUGS:Error Vulnerabilities:Vulnerabilities:$STEP_SONAR_VULNERABILITIES:Warning Smells:Code Smells:$STEP_SONAR_SMELLS:Warning Coverage:Coverage:$STEP_SONAR_COVERAGE:Default Report:$STEP_SONAR_HOST/dashboard?id=$STEP_PROJECT_GROUP_ID%3A$STEP_PROJECT_ARTIFACT_ID

set -e: Exits the script immediately if any command fails, which stops the pipeline.
cd $PROJECT_DIR: Changes the directory to the code repository path.
mvn install -DskipTests: Installs Maven dependencies.
mvn sonar:sonar -Dsonar.host.url=$STEP_SONAR_HOST: Runs a SonarQube scan.
redline ...: This function formats metrics and redline data for the UI. It uses spaces as delimiters. Each segment follows the <key>:<name>:<value>:<style> format. A report is formatted as Report:<url>. The key must match the key defined for the redline in step.yaml. The style determines the display color: Error (red), Warning (orange), Default (gray).

This affects the frontend display and generates the following output in the logs:

[stepIdentifier] STAT_INFO_TITLE: Test
[stepIdentifier] STAT_NAME_Bugs: Bugs
[stepIdentifier] STAT_VALUE_Bugs: 0
[stepIdentifier] STAT_STYLE_Bugs: Error
[stepIdentifier] STAT_NAME_Vulnerabilities: Vulnerabilities
[stepIdentifier] STAT_VALUE_Vulnerabilities: 0
[stepIdentifier] STAT_STYLE_Vulnerabilities: Warning
[stepIdentifier] STAT_NAME_Smells: Code Smells
[stepIdentifier] STAT_VALUE_Smells: 20
[stepIdentifier] STAT_STYLE_Smells: Warning
[stepIdentifier] STAT_NAME_Coverage: Coverage
[stepIdentifier] STAT_VALUE_Coverage: 0.0
[stepIdentifier] STAT_STYLE_Coverage: Default
[stepIdentifier] STAT_URL__REPORT: http://47.89.50.196:9000/dashboard?id=com.adu%3Aspring-boot-hello-world

Each metric element generates three lines of output:

STAT_NAME_xxx: The name of the field.
STAT_VALUE_xxx: The value of the field.
STAT_STYLE_xxx: The display style of the field (Error: red, Warning: orange, Default: gray).

STAT_URL__REPORT is the report link. In the UI, this creates a Report button that links to the specified URL.

To upload a local file and generate a report link, add a "Report Upload" step after this custom step.

Run locally

A step is essentially a container image, so you can run it locally. The flow CLI helps simulate a pipeline runtime environment on your local machine, including mounting code paths, caches, and pipeline context environment variables. In the sonar-qube directory, run the following command:

flow step run

Enter values for the STEP_SONAR_HOST, CHECK_REDLINES, and workspace variables. The step then runs locally.

Example of CHECK_REDLINES:

[{\"identifier\":\"10_1581409320500__10_1581421770772__CHECK_REDLINES__0\",\"key\":\"Bugs\",\"type\":\"LE\",\"threshold\":0},{\"identifier\":\"10_1581409320500__10_1581421770772__CHECK_REDLINES__1\",\"key\":\"Vulnerabilities\",\"type\":\"GE\",\"threshold\":2}]

identifier is a unique ID for the step instance and can be a random string. key is the field to validate. The type defines the comparison: LE (value ≤ threshold), GE (value ≥ threshold), or EQ (value = threshold). threshold specifies the value to compare against.

You can monitor the execution by observing the log output and verify that the expected results are generated in $WORK_SPACE/params.

This command executes docker build and docker run to run the step locally.
The input parameters are cached in the sonar-qube/params.env file, so you do not need to re-enter them for each run.
For multiple runs, Maven dependencies are cached locally in ~/.m2.
The workspace path that you provide at runtime must be an absolute path on your local machine. It is mounted to /root/workspace/code in the container. Your step.sh script can then access this path using the $PROJECT_DIR variable.

Usage within an organization

In the sonar-qube directory, run the following command:

flow step publish

This command runs docker build and docker push, and syncs the step information (from the YAML file) to your organization's step list. Run the following command to view this list:

flow step ls

Then, navigate to your organization's pipeline editor. The SonarQube step is now available under Add Step -> Custom Step.

You can use this step just like any other system-provided step.

After running the pipeline, you can view the SonarQube code quality results in the stage panel of the run details page. This includes metrics such as bugs, vulnerabilities, code smells, and coverage. Use the report and log links at the bottom to view details.

Share steps across organizations

To share the step with all Flow organizations, run the following command from the directory containing sonar-qube:

flow step public sonar-qube
flow step ls

→ step flow step public sonar-qube
→ step flow step ls
SIGN              NAME                     STATUS        CREATE TIME
sonar-qube        SonarQube                PROCESSING    2020-02-10 15:32:00
second            Custom Step              PRIVATE       2020-02-09 22:11:38
test-step         Custom Step              PRIVATE       2019-12-30 19:56:52
jintang-test      Custom Step              REJECTED      2020-01-17 16:38:53
first             Custom Step              PRIVATE       2019-12-31 19:46:39
wayne-staging     Wayne Release - Staging  PRIVATE       2019-11-28 14:51:11
→ step flow step ls
SIGN              NAME                     STATUS        CREATE TIME
sonar-qube        SonarQube                PRIVATE       2020-02-10 15:32:00
second            Custom Step              PRIVATE       2020-02-09 22:11:38
test-step         Custom Step              PRIVATE       2019-12-30 19:56:52
jintang-test      Custom Step              REJECTED      2020-01-17 16:38:53
first             Custom Step              PRIVATE       2019-12-31 19:46:39
wayne-staging     Wayne Release - Staging  PRIVATE       2019-11-28 14:51:11
→ step flow step search
SIGN               NAME            STATUS        CREATE TIME
sonar-qube-103530  SonarQube       PUBLIC        2020-02-10 15:32:00
second-103530      Custom Step     PUBLIC        2020-02-10 09:56:23
test-step          Custom Step     PUBLIC        2019-12-30 19:56:52
first              Custom Step     PUBLIC        2019-12-31 19:46:39

The status of the sonar-qube step changes to PROCESSING. You must wait for an Alibaba Cloud DevOps reviewer to perform a manual review. After the review, the status of your organization's step returns to PRIVATE. Running flow step search should now show a sonar-qube-<regionId> step, which indicates the step has been successfully made public. If the review is rejected, the reason will appear in the Notification Center in the upper-right corner of the Alibaba Cloud DevOps console.

After a step is successfully made public, two versions exist: a custom step visible only within your organization with the sign sonar-qube, and a public step with the sign sonar-qube-<regionId>. To update the public step, you must run flow step public again. All historical versions are retained. You can run flow step version <sign> to view step versions and flow step get <sign> -v <version> to view the details of a specific version.

The sonar-qube step is displayed in the Custom Step section of the pipeline editor. The location of the sonar-qube-<regionId> step is determined by the category field in step.yaml:

For example, if category in step.yaml is set to Static Scan, the public step sonar-qube- appears as SonarQube under the Static Scan category in the Add Step panel.