Don't overwrite final state of Copr build by an in-progress state

[lbarcziova]

Example logs:

2023-11-13T14:47:52.864+00:00	Status reporter will report for GithubProject(namespace="rear", repo="rear"), commit=4434da63686f0615eb6936eab7c8b96a7c80b979, pr=3073
2023-11-13T14:47:52.864+00:00	Setting Github status check 'success' for check 'rpm-build:centos-stream-9-x86_64': RPMs were built successfully.
...

2023-11-13T14:47:53.363+00:00	Status reporter will report for GithubProject(namespace="rear", repo="rear"), commit=4434da63686f0615eb6936eab7c8b96a7c80b979, pr=3073
2023-11-13T14:47:53.363+00:00	Setting Github status check 'in_progress' for check 'rpm-build:centos-stream-9-x86_64': RPM build is in progress...

[lachmanfrantisek]

Let's add a check before processing in-progress ones and do it on our (=~database) level, not on GitHub.

[mfocko]

notes from the refinement discussion

Based on the description of the issue and some of the “breadcrumbs” I've noticed in the Sentry logs, the following cause is anticipated:

1. Packit triggers the Copr build (hounds¹ get released)
2. SRPM build has finished, Copr sends an event about the SRPM being finished
3. Copr event about successful SRPM build gets put into the queue
4. Babysit catches the RPM that has already finished in the meantime
5. Once we process the SRPM build, we override the PASS/FAIL from the babysit

Ideal outcome of this card would be making sure that we don't allow transitions from finished state (success, failure, error) to the pending or in progress state.

We also discussed the issues with testing this. Thinking about it, I would suggest simulating receival of the Copr event while mocking the database model with already finished state (as described above) and expect no change in the result.

Footnotes

1. babysit task 😉 ↩