Changes LGTM +1

I fixed it again so that result ID and the data are provided whenever available.

@vmaljulin, @gnaponie Please review.

I would say that:

satisfied_requirements must show also set: scenario system_architecture system_variant

in the same way as:

unsatisfied_requirements

Otherwise it is not clear what is sattisfied.

I would say that:

satisfied_requirements must show also set: scenario system_architecture system_variant

in the same way as:

unsatisfied_requirements

Otherwise it is not clear what is sattisfied.

Yup, that makes sense. This patch adds the values to both satisfied_requirements and unsatisfied_requirements and tries to make the entries generally more consistent.

I've update documentation and functional tests.

@lholecek thank you for this fix, it is highly appreciated.

I'm going to merge this so we have enough time to test in stage before deploying to production.

So I'm curious about something here. The 'type' for TestResultIncomplete is 'test-result-missing', exactly the same as TestResultMissing. A single-line comment is the only explanation:

# Same type as TestResultMissing for backwards compatibility

there's nothing in the commit message or this PR description to explain further.

Unfortunately, this means there is no possible way to distinguish between a missing result and an incomplete one using the response to a non-verbose query, because the data you get is exactly the same for both cases. You cannot tell whether there is no indication that the test has been scheduled at all, or whether it is scheduled/running but has not completed yet. You can only tell by doing a verbose query and looking at the raw resultsdb result.

What's the "backwards compatibility" that was needed here? Is there any path to not needing it any more, and changing the type to 'test-result-incomplete'?

For the record, I ran into this as part of working on https://github.com/fedora-infra/bodhi/issues/4853 , the ticket to improve Bodhi to use queued/running test information.

Incomplete test result in policy response (unsatisfied_requirements) always has a result_id value (the latest result ID in ResulsDB with outcome QUEUED or RUNNING).

Missing test result does not contain result_id - meaning the result is required but there is none yet (with any outcome).

Previously "test-result-missing" indicated missing a completed test result so I kept the type same in case consumers/clients depend on it.

It would be probably handy to have outcome in the incomplete unsatisfied requirement entry (and perhaps some other additional info from ResultsDB). Edit: Actually never mind, this info is available in the verbose part of the Greenwave response.

aha, thanks, that should be workable, I'll try it out.