Alibaba Cloud DevOps:Automated check settings

1. Third-party CI integration based on commit status capability

1.1 Data write-back based on OpenAPI

The third-party CI integration feature allows users to write back CI results through the Commit Status OpenAPI interface. These results will be automatically integrated into the Automated Checks of code review and displayed as third-party automated check results, known as "third-party commit status." Specific features include the following:

• Status write-back: Supports writing back four statuses: success, failure, pending, and error.

• Link write-back: Supports writing back links for easy navigation to detailed execution information.

• Description write-back: Supports writing back description information, which can be rendered in Markdown format.

1.2 Setting merge checkpoints based on Commit Status

In daily development, you can set commit status checkpoints to prevent merge requests that do not meet checkpoint requirements from being merged. This configuration is in the repository Settings > > Branch Settings > > Protected Branch Rules. For more information, see Protected branches.

2. Third-party CI integration based on Check Runs capability

Codeup supports "Check Runs" as a more flexible integration method.

The Check Runs feature provides stronger extensibility and customization capabilities, supporting rich CI status enumeration, Check Annotations, and custom result display views (based on Markdown format).

2.1 Check Runs supports rich CI statuses

The status of Check Runs is determined by two parameter fields status and conclusion. When using these parameters, you can map statuses according to actual automated check results.

• status includes:

  • queued: In queue.

  • in_progress: Running.

  • completed: Completed.

• conclusion includes (conclusion takes effect only when status is completed):

  • cancelled: Cancelled.

  • failure: Failed.

  • neutral: Neutral status (this status is typically used for "automated checks that need to be executed but do not affect the final result or can be ignored," counted as a success status).

  • success: Success.

  • skipped: Skipped (counted as a success status).

  • timed_out: Timeout (timeout period for third-party checks).

  • stale: Stale (determined by the code platform; if the status has not reached status=completed after 14 days, it will be processed as stale by the platform, and only the code platform can set the check runs conclusion to stale; users cannot set this status through write-back).

2.2 Check output capability introduction

You can customize the detailed display of a Check Run by writing back the output field through OpenAPI. If you have similar customization requirements, this section covers the key information fields for UI display:

• output includes:

  • title: Title information (not the name of check runs).

  • summary: Summary information, supports Markdown format, with a maximum character length of 64KB, or 65,535 characters.

  • text: Detailed information, supports Markdown format, with a maximum character length of 64KB, or 65,535 characters.

  • images: This field contains image information to be displayed, typically no more than 3 images, and you need to ensure they are accessible, otherwise they may not be displayed.

The following shows the display of check runs when output is written back:

2.3 Check Annotation capability introduction

Check comments provide the ability to add comment information directly to code lines or consecutive code snippets during code inspection. In practice, when CI can return issues with specific code line locations, it is usually desirable to understand them intuitively in the review interface as well. Check comments are written back through OpenAPI. The following describes the specific fields:

• annotations contains:

  • path: file path.

  • startLine: starting line, beginning from 1. You need to ensure that this line can be found in the file specified by the path.

  • endLine: ending line (same as above).

  • startColumn: starting column (this field is valid only when startLine=endLine).

  • endColumn: ending column (this field is valid only when startLine=endLine).

  • annotationLevel: inspection annotation issue level:

    • notice: minor.

    • warning: warning.

    • failure: critical.

  • message: summary information of the inspection annotation.

  • title: title of the inspection annotation (this is not required, but in practice, we recommend using the title to indicate the code line and issue for quick understanding of the problem).

  • rawDetails: raw content output by CI run (as plain text format without special rendering, limited to 64KB).

Check the run details page:

2.4 Setting up merge checkpoints based on check runs

In daily development, you can set checkpoints to verify the execution results, which prevents merge requests that do not meet the checkpoint requirements from being merged. This configuration is available in the repository Settings > > Branch Settings > > Branch Protection Rules. For more information, see Branch protection. Once checkpoint items are configured, they will be displayed as mandatory checkpoint items in Automated Checks, even if they do not have execution records for the current version.

If any automated check checkpoint is configured in the protected branch, the corresponding check item in the merge request's Automated Checks will be marked as a Checkpoint.

Checkpoint items affect merge request approval, while non-checkpoint items are only displayed but do not block the process. You can configure your checkpoint requirements as needed.