Simplify UpdateReadyForTesting, publish it on edits that change builds and on update creation (backport #5538) #5549
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![mergify[bot]](https://avatars.githubusercontent.com/in/10562?s=60&v=4){kind=small}
See https://pagure.io/fedora-ci/general/issue/436 . This isn't strictly necessary, but it simplifies things and makes them more consistent. We introduce UpdateReadyForTestingV3, which now inherits from UpdateMessage and is more similar again to all the other messages. It drops quite a lot of the extra data that V1 and V2 contained because, AFAICS, the Fedora CI triggers never actually used it. It retains only what they need - a stripped version of the artifact dict with stripped build dicts. Really the triggers only need the task ID and build ID from these build dicts. Signed-off-by: Adam Williamson <awilliam@redhat.com> (cherry picked from commit 3f6aaa3)
See https://pagure.io/fedora-ci/general/issue/436 . This is the behaviour test systems want, based on real-world experience. We do not want test systems to wait for updates to reach the updates-testing repo before they test; we want them to test as soon as the update is created. All the test systems that exist pull the builds to be tested from Koji, they do not rely on them being present in updates-testing. Waiting for the update to reach updates-testing before tests run can mean a wait of up to 24 hours, which is obviously not ideal when people want test results fast. It also means we can't gate push to updates-testing on tests that trigger on this message. openQA currently listens out for other messages to use as a proxy for 'update was created' in order to mitigate this problem, but Fedora CI does not do so, and consequently its tests often trigger late. This change, along with the earlier change to publish this message when an update's builds are changed, will allow us to simplify openQA's logic considerably (it can just trigger any time it sees this message) and improve CI's scheduling considerably without any need to make changes to the trigger logic on the CI side. Signed-off-by: Adam Williamson <awilliam@redhat.com> (cherry picked from commit d3765ed)
Test systems should re-test an update if it's edited and its builds change. Before b33609d we could rely on UpdateReadyForTesting being sent (after a delay) when this happened, because editing the builds causes the update to be sent back to pending state and then to testing state, and we were publishing the message any time an update hit testing state. But now we publish the message on update creation instead of when the update reaches testing status, that is no longer the case. So instead we should directly publish UpdateReadyForTesting when an update is edited and the builds change. Signed-off-by: Adam Williamson <awilliam@redhat.com> (cherry picked from commit 5baa421)
Signed-off-by: Adam Williamson <awilliam@redhat.com> (cherry picked from commit 681119c)
mattiaverga
approved these changes
Dec 3, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automatic backport of pull request #5538 done by Mergify.
Mergify commands and options
More conditions and actions can be found in the documentation.
You can also trigger Mergify actions by commenting on this pull request:
@Mergifyio refreshwill re-evaluate the rules@Mergifyio rebasewill rebase this PR on its base branch@Mergifyio updatewill merge the base branch into this PR@Mergifyio backport <destination>will backport this PR on<destination>branchAdditionally, on Mergify dashboard you can:
Finally, you can contact us on https://mergify.com