#44 Trigger stable update tests when updates become batched too
Closed: Invalid 2 years ago by frantisekz. Opened 2 years ago by bowlofeggs.


When Bodhi updates get their request set to stable, a few taskotron tests run such as dist.rpmdeplint and dist.upgradepath.

Bodhi recently got a new request state called "batched". For the purposes of these tests, an update being batched is basically just a delayed push to stable (in Fedora, the update will go to stable on the next Tuesday).

Since batched is just a request for a delayed stable, it would be reasonable I think to run the tests that trigger on stable when this new batched state happens as well.

There is a fedmsg sent when an update is sent to batched, bodhi.update.request.batched.

I wasn't able to easily find how the current tests are getting triggered. I wonder if they are looking for the Koji tag changes instead of for the Bodhi fedmsg? The stable fedmsg would be bodhi.update.request.stable, and the Koji tag for a pending stable update is release dependent, but would be f27-updates-pending for f27, as an example. Perhaps it's currently just watching that koji tag? If so, Bodhi doesn't currently tag batched updates in Koji.

Ah yes, I see in the config examples that the tests I mentioned are triggered upon Koji tag changes. So I would either need to make a Koji tag for batched Updates, or maybe I could send a PR here that would use Bodhi fedmsgs for this.

@bowlofeggs - you might have missed my message on the IRC - this is the actual code, that we use to produce the data on which upgradepath/depcheck are triggered:
We work on top of koji-tags, and the tests' implementation is built around that.

that being said, so long as it's a repo-ish thing, we should be able to work with it

WRT rpmdeplint (aka depcheck), this is what we do: https://pagure.io/taskotron/task-rpmdeplint/blob/develop/f/runtask.yml

in layman's terms - we grab the contents of a koji tag, create a repo out of the downloaded rpm files, and run rpmdeplint on top of that, so for it to run without modification to the test, koji-tag (to be downloaded) would be required.

Upgradepath is also implemented quite tightly (from what I can tell) around handling koji tags:
So it would IMO be for the best (as I don't really see us rewriting depcheck/upgradepath) to have koji-tags for the batched updates.
Thoughts, @kparal ?

Oh that does make sense. Hmm. And we really wouldn't want Bodhi to just reuse the existing stable tag, because then a stable (i.e., not batched) update could pass the depcheck due to a dependency update being batched. Thus I think you are right - I would need to ask releng for batched tags in Koji for this to work properly.

Among our existing checks, I believe there are just 2 candidates to run when an update is marked as batched - rpmdeplint and upgradepath.

Rpmdeplint is scheduled regularly whenever updates(-testing)-pending tag is changed, and it checks all builds in updates-testing (which currently includes batched as well, IIUIC), every time. So while technically we could benefit from triggering on batched changes, in reality we run it so frequently that we probably don't need to care about this.

Upgradepath is the check that would make sense to run in batched changes, yes. Currently it's only run on updates-pending, which is too late, but there was no better option. With batched, we could do the necessary strict upgradepath checking that we need (if F25 update is batched, F26 and F27 updates also need to be batched). In this case code changes would be necessary anyway, so I could make it also react to Bodhi's bodhi.update.request.batched fedmsgs, and not just koji tag changes. Having a separate batched koji tag would probably make it a bit simpler, yes, but it's not necessary. Having said that, I saw a remark in one of the last FESCo meetings that they'll ask for upgradepath check to be de-prioritized or completely removed. That ticket is supposed to be created by @kevin, and I don't think it has been created yet, so I'm not fully clear on the reasons for this (even though I have some guesses). If this was the case, upgradepath would go away anyway.

So to conclude, I'd probably wait a bit with creating the koji tags for batched, for the purpose of current Taskotron tasks (unless you have additional reasons for having them). They might not be needed for us, at least for the time being. Sorry for responding so late in here.

We've just dropped upgradepath in taskotron#244. So for the moment I think this feature is not really needed.

Metadata Update from @kparal:
- Issue priority set to: Low

2 years ago

Metadata Update from @frantisekz:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.