Do not run specific CI jobs after merge via PR if develop has no new commits

Hi guys,

say I have a PR which is based on the latest develop and therefore there are NO new commits in develop. In my current setup the whole CI runs once in PR context and then once again after the PR has been merged. In my opinion it’s a waste of resources to rerun jobs for unit testing, linting and such because with they have been run in the latest code base.

Is there any way to improve this or is it a side-effect I have to live with for the sake of CI? Latter would be fine but I’d like to know.


You could have a thing that only relies on pull_request instead of push + pull_request.

But the odds are that you’re doing either a rebase or a merge, which means what you’re testing isn’t the same as what you’ve merged unless you always rebase the PR before merging and wait for the tests to pass on the fast-forward friendly PR.

Otherwise, imagine you have two open PRs: A and B. Both are tested as merged against main. Both pass. You merge A. Now you have main+A. You merge B into main+A. The tests would fail because a logic change that A made changes the flow for B, but because they aren’t adjacent code bits, there isn’t a merge conflict, and because of the way testing works, nothing noticed until either you run tests on main+A+B, or you try a new PR for C onto main+A+B.