[Workflow] Commits with "[skip ci]" should inherit build and test status from the previous build

[yuanming-hu]

Concisely describe the proposed feature

To save CI resources the format server always commits with the prefix "[skip ci]". This means the buildbots will not test the latest commit.

If the previous commit actually fails to pass tests, build bots working on the latest commit will not detect it. Then GitHub will show a misleading tick.

For example, a recent PR was accidentally merged and then the master branch fails to pass the tests. This is likely because the PR author considered the build status of the latest commit as the PR build status:

Describe the solution you'd like (if any)

Somehow modify the GitHub workflow so that for commits with "[skip ci]", query the last commit without "[skip ci]" and inherit the build status? @archibate is the expert in related topics.

[k-ye]

I spent some time looking into this, given how many times we've been burnt by this false positive ✅ .. I think we can have a python script that does some crawling & JSON parsing using the GitHub API:

1. Get the pull request's commits with /repos/taichi-dev/taichi/pulls/{pull_number}/commits (doc). PR number can be found in ${{ github.event.pull_request.number }}. E.g. https://api.github.com/repos/taichi-dev/taichi/pulls/1691/commits

   We can use this to find out the previous commit's SHA.

2. List out all the Github workflow runs with /repos/taichi-dev/taichi/actions/runs (doc). E.g. https://api.github.com/repos/taichi-dev/taichi/actions/runs

   To speed things up a bit, we can specify a query parameter branch=${your branch name} to narrow down the result. Branch name can be found in ${{ github.event.head_ref }}. (Unfortunately I don't think we can do a more precise search, e.g. using the PR number)

3. Each workflow run contains the commit SHA. As a result, we can find out the corresponding workflow run using step 1's result. Note that GH paginates the workflow run results, so the script might need to repeat step 2 several times.

A few catches:

• the workflow run for the previous commit may not finish yet: maybe we should just make this script spin polling the previous run's status.
• this is the first commit: just return 0...

[k-ye]

From the CI experience so far, now I think it's better to add a step to cancel the previous workflow, if there is any, when a new commit arrives. This even includes the commits from @taichi-gardener.

Right now we've made "Build and Test (CPU)" a required job to pass before merging. However, for @taichi-gardener's commits, this is skipped to save CI resources. This led to a situation where, while the previous run state is inherited by the "Checks the Workflow Run of the Previous Commit" job, we still cannot merge and have to re-trigger CI eventually...

If we choose to cancel the previous CI jobs, we can afford @taichi-gardener 's commits to go through the CIs, too. This is also how most of the CI pipelines work. I'll play with this idea a bit. Meanwhile, let me know if you have any other thought on this, thanks!