WIP: Update note of scheduled product when handling increment approval

[Martchus]

Related ticket: https://progress.opensuse.org/issues/193843

---

This is still WIP because tests are still failing as I need to add mocking for the new API call.

[Martchus]

The note would look like this on the openQA-side: os-autoinst/openQA#6895

That looks good but whether the note would very discoverable there is of course questionable. One has to go to https://openqa.suse.de/admin/productlog and type "increments" to open that page from the lengthy list of scheduled products for increments. Many of those scheduled products are probably for the same product increment but it is hard to see from the table of scheduled products what product increment they have been created for.

Maybe it would be better to simply write a comment on the product increment itself to state why it hasn't been approved. (In case we approve there's already a message.)

This is also only about increments for now as these are already mapped to scheduled products in a simple way. I suppose this could also be done for incidents although we have the dashboard for them anyway which is much more discoverable. (Of course with more dashboard-less commands like #418 having the information somewhere in openQA becomes generally more beneficial.)

[okurz]

The note would look like this on the openQA-side: os-autoinst/openQA#6895

That looks good but whether the note would very discoverable there is of course questionable. One has to go to https://openqa.suse.de/admin/productlog and type "increments" to open that page from the lengthy list of scheduled products for increments. Many of those scheduled products are probably for the same product increment but it is hard to see from the table of scheduled products what product increment they have been created for.

Maybe it would be better to simply write a comment on the product increment itself to state why it hasn't been approved. (In case we approve there's already a message.)

This is also only about increments for now as these are already mapped to scheduled products in a simple way. I suppose this could also be done for incidents although we have the dashboard for them anyway which is much more discoverable. (Of course with more dashboard-less commands like #418 having the information somewhere in openQA becomes generally more beneficial.)

Yes, given all those points I assume
https://open.qa/docs/#_test_result_badges_gh5022
for which I recently added build-support can bring us further.

[Martchus]

So, should I continue here? (It probably wouldn't be much work to adjust unit tests but I suppose I would also have to test this for real against an openQA instance.)

[okurz]

So, should I continue here? (It probably wouldn't be much work to adjust unit tests but I suppose I would also have to test this for real against an openQA instance.)

As long as product increments are bound to scheduled products this still makes sense to me and the implementation does not look too complicated. Regarding discoverability that is something we need to fix for qem-bot anyway. For now it would be good to just reference the URL to the scheduled product page in qem-bot log messages. After https://progress.opensuse.org/issues/196820 "[qem-bot] comment in gitea PRs pointing to openQA test results" we can look into putting such URL pointing to the scheduled product or whatever is the "reference" for qem-bot's approval in OBS/gitea comments.

[asmorodskyi]

see comments inline

[asmorodskyi]

we are going in circles here . ScheduleParams is list[dict[str, Any]] and we have function which is "converting" list into list . Can you elaborate why do we need this ?

[Martchus]

This is not about converting types but about turning params (scheduling parameters) into the corresponding search query parameters for the openQA API. Note that this conversion was already there before; I'm just extracting it into a function because I now need it a 2nd time and didn't want to duplicate it.

[asmorodskyi]

ok then it should be method of class ScheduleParams