discarding old CI runs for a commit

In our https://github.com/easybuilders/easybuild-easyconfigs repository, CI tests for pull requests sometimes (rightfully) fail when the PR depends on a change made in another PR.

When we were (only) using Travis CI, it was simple to re-trigger the tests by closing & re-opening the PR when the other PR it requires got merged. This triggered a new test run in Travis CI, effectively discarding the old result for the last commit in the PR.

Now that we’re (also) usign Github Actions CI, closing & re-opening a pull request also triggers a new suite of test runs, but the old runs stay there , and hence the status of the last commit in the PR will be still be failure, even if all the new GitHub Actions CI runs pass.

How can we avoid that old GitHub CI runs are taken into account to determine the status of pull requests?
Can we discard old runs somehow if we know they’re no longer relevant?

Reopening a PR triggers a new workflow run. This is a separate run and thus comes on top of the existing ones. You should however be able to press the “Re-run checks” button on a failed workflow in the “Actions” tab of your repository to trigger it again and “discard” it’s old result.

Also keep in mind that being able to see all historic runs is important mainly for private organizations/repositories that are billed for their build minutes and thus need to be able to see a breakdown of those costs. Simply “removing” a run would make the billing untransparent. Travis CI has no limit in build minutes on their plans, so it is no issue there to “remove history”. (Although I believe you can still see it when you go to the Build History tab.)

Thank for you the answer, that’s helpful.

I understand that there are good reasons why the results of the old workflow are not discarded automatically, but is there no way to specify this in the workflow config?

A close/re-open can be done by the contributor, but doing a manual re-run of the workflow via “Re-run checks” is not, which implies the people with repository admin rights need to take care of it…

@boegel wrote:

I understand that there are good reasons why the results of the old workflow are not discarded automatically, but is there no way to specify this in the workflow config?

There is currently no way to set that kind of behaviour, no.

@boegel wrote:

A close/re-open can be done by the contributor, but doing a manual re-run of the workflow via “Re-run checks” is not, which implies the people with repository admin rights need to take care of it…

I am not 100% sure if the person that triggered the workflow cannot re-run it and if it’s just reserved to admins. But there’s a good chance that it is.

After trying to reproduce your scenario, I think I see what you’re getting at. I would NOT expect the red outlined actions to “stack” in this overview. They should be there just once per workflow. I WOULD expect them (and I thought you were talking about this) to appear in the green outlined Actions tab for each individual run. They should not be “discarded” there.

Whenever updating a PR (e.g. pushing a new commit), the existing workflows are replaced in this overview, so I wouldn’t see why reopening one should behave differently in that regard. I would consider this a bug.