Packit-service: Smarter policy for /packit build

[StykMartin]

It may seem obvious to not run /packit copr-build command twice.

However, it may happen that my colleague will decide to be proactive and post comment for a build at the same moment as I'm. This will cause 2 builds and wasting for COPR resources + ref status is updated twice. So if one build was lucky enough in all aspects you will get passed everywhere and 30 second later this status is replaced with a new one. In worst case with failures.

End goal:

• Only one build can provide result
• Rebuild is still possible - meaning wait till I have results and then rebuild if COPR screwed it (hello mirror fedora issue)
• Less confusion
• ??? Definitely profit

Possible solutions:

• Ditch previous builds and start a new one
• Do not accept new builds until current is running

[lachmanfrantisek]

This is applicable not only to comments. It would also be nice to solve this in general (e.g. for multiple pushes in a short while).

We need to see if we can easily kill the already running build.

[jpopelka]

Related: #5

[TomasTomecek]

This is applicable not only to comments. It would also be nice to solve this in general (e.g. for multiple pushes in a short while).

We need to see if we can easily kill the already running build.

Copr provides a way to cancel builds:

copr_client.build_proxy.cancel()

This should be easy to implement: just check if a build in the PR copr project is running, if it is, cancel it and submit a new one.

[lachmanfrantisek]

Related: #5

@jpopelka, thanks for linking that issue.

Let's mark this one as a duplicate and focus on the other issue..

Duplicate of #5

[csomh]

I think @jpopelka marked #5 as "related" for a good reason. There are 2 cases here, when "duplicate" builds have to be dealt with:

1. a duplicate /packit build command is issued, but a build for the git ref is already running - this is the case this issue was filed for.
2. a new commit is pushed into the PR, rendering a build still running for the previous commit unnecessary - this is the case #5 was filed for.

On a high level implementing something that would cover both of the scenarios above would look like (pseudo code):

build_trigger(command or push event):
    if build for current git_ref is running:
        ignore trigger
        return

    # for branch pushes it's probably okay to let builds for prev commits finish
    if build for current pr is running:
        cancel current build

    start new build

Optionally a /packit rebuild command could be provided for cases, when one would like to cancel a currently running build and restart a new one from the same commit. Could be used in cases, when one sees a build will fail due to infra issues, but doesn't want to wait until the failure reaches Packit.

Edit: I've re-opened this to make sure none of the aspects above are forgotten.

[lachmanfrantisek]

@csomh I've closed this one to move the discussion to one place...

Can you please copy your (valid) comment to the #5 and close this one after that? Thanks!

[csomh]

@lachmanfrantisek convinced me that cancelling running jobs is the way to go: will provide one solution for all similar issues and the behaviour is consistent with other tooling (like zuul).

Updated #5 to make sure we don't forget about jobs started as a result of commands. @StykMartin please subscribe to that one if you are interested.

Closing this, this time for real :bomb: :boom: :boom: :boom: