pagure

#2940 After PR is modified by force push, CI is only triggered when PR page is visited
Closed: Fixed Opened by adamwill.

Closed: Fixed
Reopen Issue

On my workflow at least, there seems to be an issue with CI job triggering for PRs.

I usually create a PR from the web UI, so of course the browser hits the page at the end of the PR creation process, and the CI job is triggered.

However, I typically amend PRs by amending the commit locally and force-pushing the branch. I've noticed that when I do this, the force-push does not actually trigger a CI job...but if I visit the PR page in the web UI after such a force-push, a job is triggered.

I have not checked if the same applies to non-force-push situations, e.g. adding a commit to an existing PR - I don't know if you have to hit the PR page after doing that to force a CI job to fire. But it definitely seems to apply to the force-push case.

So there is already logic in the default hook to do this, but it seems that if you're using a fork/PR model it is flawed and it basically refresh the PR's cache on the fork rather than the main project.

Metadata Update from @pingou:
- Issue assigned to pingou
- Issue tagged with: bug, easyfix

It applies to non-force push as well. I ran into this as well and worked around by enabling fedmsg hook in the fork and writing a consumer to refresh the page after push. Having this work automatically would be nice though.

Commit 60b4f186 fixes this issue

Does this make Simple Koji CI scratch rebuild packages when there is a force push to src.fp.o PR?

@churchyard the commit above doesn't no (it was solving the fact that a page refresh was needed to trigger a refresh of the PR itself), but https://pagure.io/fedora-ci/simple-koji-ci/pull-request/14 does re-trigger a scratch build when the PR is updated.

Thanks for clarifying and that PR.
Metadata

bug easyfix

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.