[M] Give Bodhi automation to push based on time in testing

[bowlofeggs]

Right now Bodhi has the ability to push updates to stable when they reach a karma threshold, but updates that reach the time in testing need to be manually pushed by a packager.

This RFE is about giving Bodhi the ability to automatically push the update to stable when it reaches the time in testing, so long as it does not have any negative karma (negative karma currently stops autopushing based on karma, so we want something similar for time).

This has been approved by FESCo, and here is a list of requirements from that ticket:

• The boolean to select push based on time should be independent from the existing boolean to push based on karma.
• The packager should be able to set the number of days they want it to wait, not less than the release's minimum days (i.e., for Fedora they could set it at 7 days on the low end, or 30 if they like 30).

[bowlofeggs]

We need this for Rawhide Gating too, so that updates get moved to stable automatically when the CI tests pass on Rawhide.

[cverna]

We need this for Rawhide Gating too, so that updates get moved to stable automatically when the CI tests pass on Rawhide.

If I understand it well what we need for rawhide gating is not exactly the same this ticket is about automatic pushing based on time while rawhide gating is based on the CI test. Are we planning to implement both feature at the same time ? or should we create a specific ticket for automatic push based on the CI ?

[cverna]

For rawhide gating we will use time base pushed but time will be set to 0.

[cverna]

The packager should be able to set the number of days they want it to wait, not less than the release's minimum days (i.e., for Fedora they could set it at 7 days on the low end, or 30 if they like 30).

I propose to implement this in a second step, I don't think it is critical for rawhide gating and it will make this change simpler. What do you think ?

[bowlofeggs]

On Thu, 2019-03-21 at 05:12 -0700, Clement Verna wrote: I propose to implement this in a second step, I don't think it is critical for rawhide gating and it will make this change simpler. What do you think ?

Since this issue is tied to a FESCo decision, I think we should implement it as discussed in the FESCo ticket and should not partially implement it.

[cverna]

What should be the default value for the number of days in testing ? As far as I know when creating an update we do not know yet the release associated with this update, so we can't have a per release default value.

Maybe we can leave the input field blank and validate the input so that it is >= to the release mandatory_days_in_testing but that will provide a poor user experience (having to guess what is the mandatory value).

Any ideas ?

[cverna]

I have opened #3090 with what I got so far.

[cverna]

So fesco approve in today's meeting the possibility to so that in 2 phase, with phase 1 being without the option to change the time spent in testing required by an update.

I think we should consider this option, except if we have a nice way to handle how to manage the UX for updating the number of days in testing required.

[bowlofeggs]

On Mon, 2019-03-25 at 01:22 -0700, Clement Verna wrote: What should be the default value for the number of days in testing ? As far as I know when creating an update we do not know yet the release associated with this update, so we can't have a per release default value. Maybe we can leave the input field blank and validate the input so that it is >= to the release mandatory_days_in_testing but that will provide a poor user experience (having to guess what is the mandatory value). Any ideas ?

I think we can allow it to be empty in the form, and that should mean that the user wants it to be the release's value. If the user sets a larger value, that's fine. If they set a smaller value, I think we should just force it to the release minimum and we can inform them that we did this via Bodhi's caveats API. This way there is no value that can lead to an error (thus, no poor user experience).

[bowlofeggs]

On Mon, 2019-03-25 at 11:20 -0700, Clement Verna wrote: So fesco approve in today's meeting the possibility to so that in 2 phase, with phase 1 being without the option to change the time spent in testing required by an update. I think we should consider this option, except if we have a nice way to handle how to manage the UX for updating the number of days in testing required.

The complexity of releasing this with backwards incompatible changes is larger than the complexity of adding a single new UX element to hold an int. I think we should just do this in a single phase.

[cverna]

I think we can allow it to be empty in the form, and that should mean that the user wants it to be the release's value. If the user sets a larger value, that's fine. If they set a smaller value, I think we should just force it to the release minimum and we can inform them that we did this via Bodhi's caveats API. This way there is no value that can lead to an error (thus, no poor user experience).

Ok let's do that, I guess this is the least worst experience 😄

[cverna]

Fixed by #3090

[gsauthof]

Hm, is there some documentation on how to enable this feature when I submit a package update?

In a current submission I just see Autopush (time) disabled on the bodhi page.

[cverna]

@gsauthof using the latest cli (version bodhi-4.1.0-3.fc31) you can look at the bodhi updates new or bodhi update edit command and use the --autotime flag. (full documentation https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates)

Otherwise editing the update in the web interface will let you set the Autopush (time) option to True (it is a radio button)

[gsauthof]

@cverna hm, I'm used to fedpkg update - under Fedora 31, I don't find an autotime/autopush option for fedpkg update - also no autotime key in the bodhi.template that I can edit in my $EDITOR when I invoke fedpkg update without options.

I'm using:

fedpkg-1.37-9.fc31.noarch
bodhi-client-4.1.0-3.fc31.noarch

Are there any plans to add better support to fedpkg for this feature, as well?

PS: I'm looking at the edit dialog in the bodhi web-ui, and the feature now seems to be called 'Auto-request stable based on time?' which seems to be enabled, by default.

It has a parameter 'Stable days' which is set to 7. I presume this means that an update is auto-pushed after being 7 days in testing. Perhaps it's just me, but calling it 'Stable days' kind of is a misnomer then.