Differentiate between "empty result of targets_override" and "don't use targets_override"

[nikromen]

Surprise :) new edgecase bug discovered for /packit retest-failed 🐛
/packit retest-failed restarts everything on these circumstances:

• both - tests jobs and copr-build jobs in packit.yaml must be enabled
• some RPM build has to fail -> test for this chroot is not started
• on /packit retest-failed -> every test is restarted

This is caused because of previously failed build: build fails -> test is not started (but ends up with a failure and with message that RPM build failed so we don't run test). That means there isn't any failed test in the database so set of chroots to override of /packit retest-failed is (correctly) {}. And here comes the issue - when targets_override are {} or None we build/test for every chroot.

Correctly, the user should call /packit rebuild-failed (but a mess happens when he does it wrong way).
You can try/see this behavior here
(This behavior obviously reveals when user calls rebuild/retest on fully passed builds/tests)

Possible solution: we should differentiate between {} and None in targets_override. If result is {} - we should "override" targets with "nothing" (or just ignore it).

And we should copy the behavior of /packit test for this - when RPM build fails and user triggers /packit test again, we notify the user with The latest build was not successful, not running tests for it. . We should respond to user the same/similar note when he tries to retest-failed, but there was previously failed RPM build.

TODO:

• ignore building/testing when result of targets_override is empty set.
• when user does retest-failed on tests where RPM build failed - provide a note that latest build was not successfull

[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]

Verified this use case still doesn't work as expected in packit/hello-world#1432: every test was restarted, but for the one with the missing successful build, the status was immediately The latest build was not successful, not running tests for it.