Note: the purpose is to be able to implement the build-breaker feature when doing "regular" (= publish mode) analyses. It does not cover the build-breaker feature when doing "preview" analyses.
- I'm doing continuous deployment of my web application and in my CI pipeline, I have a step that runs a SQ analysis to verify the quality gate and prevent a deployment if it is red
- I have automated my release process and I want this automated process to stop if the quality gate of the code being released is not green
This build-breaker feature is already achievable in SQ 5.2.
In 5.2, once the SQ analysis has sent the report to the server, it ends "successfully" and prints out a WS URL that can be called to verify the status of the report processing. Example:
12:46:11.149 INFO - Analysis reports sent to server in 27ms
12:46:11.150 INFO - ANALYSIS SUCCESSFUL, you can browse http://localhost:9000/dashboard/index/fab:one-class-project
12:46:11.150 INFO - Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report.
12:46:11.150 INFO - More about the report processing at http://localhost:9000/api/ce/task?id=AVDXd-hIzO-cOxQDPc9j
The call to /api/ce/task WS mainly gives the status of the report processing: PENDING, IN PROGRESS, SUCCESS, FAILED, CANCELED.
This means that one could already implement the build breaker by doing the following:
- Run the SQ analysis
- Call /api/ce/task until the status is SUCCESS or FAILED
- If the status is FAILED => break
- If the status is SUCCESS => immediately call /api/resources?metrics=alert_status&resource=xxxx to check the status of the quality gate
First: we don't want to parse the logs to know which WS URL to call =>
Second: we need to keep more details about the analysis results so that there's no need to call the /api/resource WS =>
- First because this WS call returns the information related to the latest analysis - which is OK if the call is run immediately after the report processing is finished but which does not guarantee that it's the correct status
- And then because it's an old and buggy WS
Third: it currently takes admin permissions to successfully call report processing status WS. We'll probably have to allow users that have the "Run analysis" permission to access this WS. =>
- This point needs to be discussed and challenged.