After discussion in the doris community @apache/doris-committers , we limit the PR to be merged only after at least two people approve it.↳
We can try to run it for a while first, and if everyone gives good feedback, we can use this as a mandatory check.
Since the merge must be approved by at least one committer, we only need to judge whether there are two approves, and we don't need to care about the identity of the approve.
When there is a request change, if the other party is a committer, the committer dismiss is required when merging, which is enforced by github, so we don't need to care.
* add clickbench and arm pipeline trigger；test merge check
* set compile required; add clickbench and arm pipeline trigger to buildall;
* avoid duplicate builds
* simplify auto trigger code and avoid repeated triggers 0310
In `Build Third Party Libraries (Linux)` job, some errors occur due to the package conflicts. This PR fixes these errors by skipping the command `apt upgrade`.
```
Unpacking odbcinst1debian2:amd64 (2.3.11) ...
dpkg: error processing archive /tmp/apt-dpkg-install-SY6NPA/43-odbcinst1debian2_2.3.11_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/libodbcinst.so.2.0.0', which is also in package libodbcinst2:amd64 2.3.9-5
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)1
```
Apache Doris made the branch branch-1.2-lts protected. As a result, all pull requests for this branch should be checked before merging it.
However, the BE UT workflows doesn't support branch checks and they fail to check the pull requests for the branch branch-1.2-lts. The reason is that they download the wrong pre-built third-party libraries when they check the pull requests for branch-1.2-lts.
In #14533 , we run BE UT workflows periodically to share the cache with brand new pull requests. However, we don't need to save the cache when the unit tests doesn't run, otherwise it may occupy huge cache space and some useful caches will be evicted by GitHub.
Currently, we build the third-party libraries and release them automatically (See https://github.com/apache/doris-thirdparty/pull/13). We must make sure that the changes for third-party libraries are valid.
> Due to the dangers inherent to automatic processing of PRs, GitHub’s standard pull_request workflow trigger by
default prevents write permissions and secrets access to the target repository. However, in some scenarios such
access is needed to properly process the PR. To this end the pull_request_target workflow trigger was introduced.
According to the article [Keeping your GitHub Actions and workflows secure](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) , the trigger condition in
`shellcheck.yml` which is `pull_request` can't comment the PR due to the lack of write permissions of the workflow.
Despite the `ShellCheck` workflow checkouts the source, but it doesn't build and test the source code. I think it is safe
to change the trigger condition from `pull_request` to `pull_request_target` which can make the workflow have write
permissions to comment the PR.
