1. What is Github Checks

Github checks consists of a series of checking tasks, designed to verify whether the basic functions of doris pass.

When a Pull Request is submitted, Github Checks are automatically triggered.

The following Checks are REQUIRED, and only after passing these checks can the code be merged:

FE UT (Doris FE UT): FE unit tests will be executed: sh run-fe-ut.sh --run
BE UT (Doris BE UT): BE unit tests will be executed: sh run-be-ut.sh --run
P0 regression (Doris P0 Regression): Will execute the compilation of FE and BE (sh build.sh --fe --be), and build the Doris environment of 1 FE and 1 BE, and execute regression test(sh run-regression-test.sh --run)
License Check / License Check: License check, will check whether all source files contain Apache License Header
Build Extensions / Build Extensions: Will compile fs_broker(cd fs_brokers/apache_hdfs_broker/ && sh build.sh) and docs(cd docs && sh build_help_zip.sh && npm install && npm run build)
BE Code Formatter / Clang Formatter: BE C++ code format check(sh build-support/check-format.sh)

The other Checks are NOT REQUIRED. Which means, even if these checks fail, it does not affect the merge of the Pull Request.

2. How Checks are triggered?

All checks are automatically triggered when a Pull Request is submitted, or when the Pull Request is updated.

The Checks 1,2,3 are triggered by TeamCity. The TeamCity service will detect the change of Doris Pull Request every 10 minutes and trigger the corresponding check(TeamCity Pipeline).
The Checks 4,5,6 are triggered by Github Action. They will be triggered immediately after PR is submitted or updated.

3. Checks Guidance

3.1 Github Action

Github Action use Github hosted VM to run the Checks.

You can click "Details" button behind the Checks to see the build log of the corresponding Check.

3.2 TeamCity Pipeline Guidance

TeamCity Pipelines are running on self-hosted VM.

3.1.1 What is TeamCity Server Address

Before you start, you need to know the open source community pipeline address: http://43.132.222.7:8111. Ordinary users can view it as a guest (Log in as guest), or jump directly to the pipeline details page from github.

How to check pipeline results in github

This method is suitable for only checking the build results of a certain pull request

1. Find the target pull request

Find the target pull request in the git repository of apache/incubator-doris

2. Check teamcity build results in github

On the details page of the target pull request, drop down to the "Review required" section, slide the gray bar on the right, and find the FE UT (Doris FE UT), BE UT (Doris BE UT), and P0 Regression (Doris P0 regression) tasks. A green tick indicates that the build task succeeded, and a red cross indicates that the build task failed. The build result of pull/8901 is shown here

3. Redirect to teamcity to check the specific build task information

Click "Details" on the right side of the construction task, you can jump to teamcity to check the specific information of the build task. The navigation bar of the construction information page contains 5 parts: Overview will give a simple report of task execution; changes will show that the build task involves repository, branch, commit history and other information; Tests will display the result of the case execution. If you want to view the failure details, you can click "Failure" on the left side of the failure case to jump to the specific error information page; the Build log will display The specific log of the task execution, supports retrieval, and supports global log download; Artifacts refers to the content of the task release, but the three pipelines of doris are not involved.

How to check pipeline details in teamcity

This is more appropriate if you want to view the build history of many pull requests

1. Choose "Doris" project

2. Get the specific pull request implementation

2.1 Get the latest execution task of the pull request

Filter the pull request you want to get on the right side of the Doris project, and expand the sub-project to see the latest record details built under the pull request. Green indicates that the build was successfully executed, red indicates that the build task failed, and the reason for the failure is displayed. Taking pull/8901 as an example here, the latest build task of pull/8901 in each subproject is queried in the Doris project. The execution of FE UT fails, and the execution of BE UT and P0 Regression succeeds.

2.2 Get the historical execution tasks of the pull request

If you want to view the historical task records built by the pull request, you can select a branch under each subproject, and you can get the historical records of the branch execution.

3. Get the details of a specific task

Click the task id to jump to the task details page, and select the information you want to view in the navigation bar. Overview will give a simple report of task execution; changes will show that the build task involves repository, branch, commit history and other information; Tests will display the result of the case execution. If you want to view the failure details, you can click "Failure" on the left side of the failure case to jump to the specific error information page; the Build log will display The specific log of the task execution, supports retrieval, and supports global log download; Artifacts refers to the content of the task release, but the three pipelines of Doris are not involved, ignore. If you haven't found a build task matching the target branch here, you can continue to step 4.

4. checking pending builds

If the branch construction task has not been found in the previous steps, the target task is still in the queue and has not been scheduled. You can go to "Queue" and use the target pull request to perform a global search to check whether the task is in the queue.

Page tree

1. What is Github Checks

2. How Checks are triggered?

3. Checks Guidance

3.1 Github Action