cockpituous workflow fails in PR with existing cockpit CI tests

[allisonkarlitskaya]

• push a change to origin which will trigger the cockpituous workflow
• (quickly) cross-check the change by triggering a bunch of tests on other projects (image:fedora-39 image:rhel-8 for example)
• notice that the cockpituous workflow fails

If the workflow runs before you trigger the additional tests, there's no issue.

This happened in a real PR: https://github.com/cockpit-project/bots/actions/runs/8771650193/job/24069674463

Just to prove that the issue is unrelated to that PR, I made a trivial test PR, similarly impacted: #6251 → https://github.com/cockpit-project/bots/actions/runs/8771878074/job/24070186097?pr=6251

From the log, you can see that the test gets caught waiting for the unit-tests status to appear, but it seems to get lost in the flood somehow. But: the unit-tests status is not present on the PR either, so it apparently fails to get queued at all. I guess that's an issue with tests-scan not triggering on PRs that already have tests triggered, but it's a bug in any case...

I guess we normally avoid this problem since image refreshes (normally the only things that trigger so many statuses) don't trigger a cockpituous workflow run.

[martinpitt]

The reason for that his that the integration tests call tests-scan on the PR, but tests-scan doesn't do anything if the PR already has any "cockpit CI" status. I'm aware of this, but this is awkward to fix -- we'd either need an integration test special case in tests-scan (which then doesn't test reality), or drop that "existing statuses" check (which feels wrong).

So far the "workaround" is to wait with triggering real tests until after the cockpituous test ran. It fortunately doesn't happen very often.