Merge Queue – Status Checks for Merged PRs

[jameskraus]

Select Topic Area

Product Feedback

Body

I work on a repo where there are CI checks that run for PRs, for the merge queue, and for the main branch. When we merge a PR, it's possible to view the status of CI checks when it's in the merge queue, and it's even possible to see the status of the CI checks if the merge fails, but if it succeeds there is no way to view the status of the CI checks once the PR makes it into main. I think the status is sort of supposed to show up on the commit on the main branch, but that is immediately overwritten by the CI which happens on the main branch.

This missing status makes it a bit difficult to audit what happened, how a PR merged, and what might have gone wrong in the merge queue. I would really love to see the status checks for the merge queue on a given PR.

[SandeepLakka]

One way I can think of is the following, please check if this suits your requirement

Using gitHub Actions workflow, we can create a gh actions workflow or update the existing workflow that comments on the PR with the CI status when the PR is merged into the main branch. This way, you have a historical record of the CI status for each PR.

Similar code like below can be placed to make it work

jobs:
  notify_ci_status:
    runs-on: ubuntu-latest
    steps:
      - name: Check CI Status
        run: |
          # Add logic here to check the CI status and post a comment on the PR.
          # You can use GitHub's REST API to post a comment.
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

API call would be like the following

          curl -X POST -H "Authorization: token $GITHUB_TOKEN" \
          -d "{\"body\": \"CI Status: $CI_STATUS\"}" \
          "https://api.github.com/repos/${GH_REPO}/issues/<PR#>/comments"

Regards,
SL

[sparrowt]

if it succeeds there is no way to view the status of the CI checks once the PR makes it into main. I think the status is sort of supposed to show up on the commit on the main branch, but that is immediately overwritten by the CI which happens on the main branch.

If the exact same CI check runs on main, which already ran in the merge queue, then the solution should be to just stop running it on main - a primary benefit of the merge queue is that it guarantees you won't break master. It generates what would be the merge commit, then runs CI on it, and then (if all is well) it updates master to "be" that exact same commit.

So effectively there's no point in running the same job on the exact same commit twice (once in the merge queue, once on main). If you have extra extended CI which only runs on main that is fine, but that will report a different check name and so won't overwrite the one from the merge queue.