Editing a PR title or first comment causing a pile up of runs


RE: https://github.com/neofinancial/ticket-check-action

I have an action that is published and overall works as expected. The purpose is to check the title, and body with regular expressions for any sort of indication that it starts with a ticket ID or contains a reference to one. It’s intended primarily for use with Jira or other off-site (meaning not GitHub) project management systems.

On initial run it works as intended, however it if fails, the fix is not actually related to a code change at all.

So i’d expect that I could edit the title or the body of the first comment and it would:

  1. Flush the current checks
  2. Rerun the workflows

Alternatively I’d also accept

  1. Trigger the workflows meant to run on the edited event, and then overwrite the old status with a matching name

Currently this is not the case and instead the workflows will bubble up. This wouldn’t bother me at all except if the bubbled up workflows fail at any point (and are required) they are not overwritten, meaning a merge is blocked until an empty commit at the very least is pushed to retrigger the whole set of workflows.

Is there a fix for this, or a solution that can be developed on GitHub’s end?

I made an example repo to show the sequence.

In master the action looks like this

name: Pull Request Lint

    types: ['opened', 'edited', 'reopened', 'synchronize']

    name: ticket check
    runs-on: ubuntu-latest

      - name: Check for ticket
        uses: neofinancial/ticket-check-action@v1.0.0
          token: ${{ secrets.GITHUB_TOKEN }}
          ticketPrefix: '#'
          titleRegex: '^#(\d+)'
          bodyRegex: '#(\d+)'
          bodyURLRegex: 'http(s?):\/\/(github.com)(\/pqt)(\/gh-community-action-example)(\/issues)\/\d+'

When that runs (and fails, as expected) on a PR without an issue ID it will fail and merge block.

I’d expect to be able to edit the body contents (or title) and adjust this to a passing status, and it does. Sort of.

You may notice that the check was successful but still requires an admin override to merge (if the protected branch does not allow admins to override then there’s no option to merge).

The checks history does not overwrite and the initial failure is _ still _ blocking the merge even though it’s no longer causing a problem.

@pqt ,

I have tested like as the situation you said, and I also can reproduce the same problem.

I guess (but I’m not sure), this is because these two runs are based on the same Git ref , and it needs all the required checks for the same Git ref must pass.

I have reported this question to the appropriate engineering team for further investigation and evaluation. If they have any progress, I will notify you in time, and sometimes the appropriate engineers may directly reply you here.

1 Like

I agree, it seems to be related to when the commit hash changes that a new set of checks are made.

Even a button to manually re-trigger checks would be enough to fix this problem.

@pqt ,

Sure, you can manually re-run the failed check-suite ( workflow run ) via the " Re-run jobs" button. You just need to open the " Checks" tab of the PR, expend the failed check-suite and select any one of the check-runs ( jobs ) under this  check-suite , then you can see the " Re-run jobs" button in the upper left corner, click it. You need do like this for each check-suite you want to re-run.

You can’t in this case however because the most recent check was successful.

@pqt ,

All right, you may have misunderstood my reply.
I mean you should re-run all the failed check-suites that contain the required check-runs for the same Git ref (here I mean  commit SHA ).
Take the screenshot you shared in your reply as an example, there are 4 check-suites run on the latest commit SHA ( cf871a1 ). We can see the first check-suite is failed, and it also contains the required check-run, you need to expend this failed check-suite to re-run it like I mentioned in above reply.

Ah! Okay yes I did misunderstand you.

I went to specifically that check and re-ran the job.

Interestingly, it failed again! I’m assuming it’s cached the contents or something else funky is happening?

@pqt ,

I tested and checked, and it is very strange that when I re-run the failed failed check-suite, it still referenced the old titile and body, even if I had updated the titile and body.

Looks like, we need to push an empty commit to trigger a new workflow run on the PR.

Not sure if there’s been any update on this at all yet? Still a little in the dark with what to expect, like whether this is going to eventually change or if the behaviour is working as intended.