Cancel running jobs when new ones are started for a PR

[TomasTomecek]

It can easily happen that a PR can receive a push or a /packit copr-build command and then another one in a short time-span.

In order to not to waste resources and avoid publishing results from a parallel set of jobs into the same PR, we should cancel old jobs (builds, tests) and submit new ones.

[TomasTomecek]

I wonder if copr optimizes this on its own - cancels old builds if new are requested in a project.

[TomasTomecek]

with postgres this can be now done so easily honestly

[TomasTomecek]

we should still investigate if copr can do this on it own

[lachmanfrantisek]

Related to #785

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[lbarcziova]

We discussed this and decided we will drop this issue since we are not able to plan this in the near future and the implementation could be more complex (since the codebase changed a lot since opening this issue) and lead to race conditions.

[lbarcziova]

Reopening given the increased user base and since it would help with resource management and address challenges such as handling outages where queues become overloaded. This would prevent unnecessary triggers of builds/tests when a pull request is updated during such outages.

This was also asked by @evgeni in the chat recently.

[bocekm]

+1 to this RFE!

When I trigger copr building and integration test execution on https://github.com/oamg/convert2rhel PRs, that's a lot of jobs. When I trigger that all again, for example by pushing to the PR branch, before even copr builds are created then the Testing Farm jobs that follow up after copr builds don't need to be even run. That might even save some GitHub App requests which are limited and our project has been hiting the limit https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?primary-rate-limit-for-github-app-installations=&apiVersion=2022-11-28#primary-rate-limit-for-github-app-installations.