Some status checks not being updated with multiple PR-triggered `copr_build` jobs sharing the same copr project

[nforro]

beaker-project/beaker has 3 copr_build jobs with pull_request trigger and different chroots configured.

It seems that on PRs in that repo (example) at least one status check always gets stuck in SRPM build succeeded. Waiting for RPM build to start... even though the build and the job finished successfully.

From the logs, it looks like in such cases the org.fedoraproject.prod.copr.build.start message is received by the fedmsg consumer but not processed further, so the status check is for the first time updated by SRPM build start event, then again by SRPM build end event, and then after corresponding org.fedoraproject.prod.copr.build.end is processed the handler ends with Copr build <ID> is already processed (status=success). As far as I can tell, babysit task doesn't play a role in this, it just repeatedly reports No feedback for copr build id=<ID> yet.

[lbarcziova]

I would say for this usecase the identifiers should be utilised to prevent this. We could make this more explicit in docs, WDYT?

[lbarcziova]

@nforro after our discussion on standup, I had another look into the code and really think the reason of this is not using identifiers, as it means that any of the builds can be processed by handler created for any of the jobs (as we do not check targets match in pre-checks). And if e.g. build for epel-7 is processed by the handler for job config where epel-7 is not in the targets list, the model in DB is updated, but the status is not reported (as when reporting, we do something like target in self.job.targets).

[nforro]

Ok, that makes sense, I didn't realize that. In that case I think it's fine to document this and have the users use identifiers.

[nforro]

The documentation has been updated - users should use identifiers to avoid this behaivor.