Allow scheduling products for product increments

[Martchus]

• Determine relevant architectures and build numbers from the files in the directory listing of the download repository of the OBS/IBS project targeted by the product increment request
• Add additional flag to create a scheduled product if no jobs have been created yet

This PR depends on os-autoinst/openQA#6798.

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

[d3flex]

I thought that the schedule logic will be encapsulated in another Class, which it will have to reuse some logic from IncrementApprover. Now it is tight to the IncrementApprover but the scheduling should be more generic.

[Martchus]

Now it is tight to the IncrementApprover but the scheduling should be more generic.

I don't think it makes sense to create another class for scheduling function that is less than 20 lines of code unless we really want to use it independently of the approver. However, for now I'd like to treat this as one task for the sake of simplicity (instead of splitting it into different commands).

[Martchus]

By the way, with this products are scheduled and on subsequent runs the very same products will be checked for results and the increment possibly approved.

We now could try to integrate any code @d3flex already has for determining the changed packages in an incident and add additional variables for the scheduled product based on that.

---

EDIT: I've just read the following on Slack:

Yes, SMELT can fetch and display product increments and even their deltas now.

So maybe we can actually make use of this SMELT feature. I'll explore this even though it is a bit out of scope for https://progress.opensuse.org/issues/190251.

[Martchus]

This PR changes the meaning of some of the arguments a little bit as they now act as a filter. So I'll change the descriptions.

I don't think it makes sense to still support the previous behavior where you would use these arguments to refer to the scheduled product with static parameters because this way it isn't possible to know whether that scheduled product is actually relevant. (E.g. an existing scheduled product might be from a previous build so we need to take at least the build number into account and that's a dynamic parameter. It would probably also be always good to avoid hardcoding the other parameters like all relevant archs in the pipeline schedule.)

[d3flex]

As part of the os-autoinst/openqa-trigger-from-obs#322 I ended up using the dist.suse.de, as that was what the rsync commands used. I still do not know whether is better than download page but I just want to let you know.

[Martchus]

I guess I'll keep using whatever OBS_DOWNLOAD_URL points to for now for the sake of consistency with the rest of the codebase. It is quite nice to be able to use ?jsontable=1 to avoid parsing HTML which I think is only possible with download.suse.de right now.

[d3flex]

fact. ?jsontable=1 is not possible in the other page

[mergify]

This pull request, with head sha 6142b2ff314b2a616497699a50befc14b57e413d, has been successfully merged with fast-forward by Mergify.

This pull request will be automatically closed by GitHub.

As soon as GitHub detects that the sha 6142b2ff314b2a616497699a50befc14b57e413d is part of the master branch, it will mark this pull request as merged.

It is possible for this pull request to remain open if this detection does not happen, this usually happens when a force-push is done on this branch increment, this means GitHub will fail to detect the merge.

[Martchus]

And now that I wanted to push changes requested in #235 it got merged…