write a rawhide test monster consumer #88

Closed
ralphbean opened this Issue Nov 9, 2012 · 8 comments

Comments

Projects
None yet
4 participants
Contributor

ralphbean commented Nov 9, 2012

Make a consumer that, for every successful rawhide build, test to see if any of its dependants broke. If they did, try a simple revbump and rebuild to see if that fixes things.

Contributor

ralphbean commented Mar 27, 2014

I think this fits much better as a taskotron test.. and there are plans for that there. Closing as wontfix.

@ralphbean ralphbean closed this Mar 27, 2014

dumblob commented Mar 28, 2014

Well, to me it seems rather different - the tasks are quite limited (e.g. I can't imagine it to schedule revbump and rebuild) and the whole taskotron seems completely dependent on koji - i.e. this will not be usable with other rpm build systems (Copr, OBS, ...). In other words, this is not testing issue, but a rolling-release issue.

I'm currently running a project which uses fedmsg to react on ABI-backwards-incompatible so-bumps and rebuilds all direct dependencies.

Contributor

ralphbean commented Mar 28, 2014

I'm currently running a project which uses fedmsg to react on ABI-backwards-incompatible so-bumps and rebuilds all direct dependencies.

That sounds useful. Link?

dumblob commented Mar 28, 2014

https://fedoraproject.org/wiki/Summer_coding_ideas_for_2014#FedmsgSobumper
https://fedoraproject.org/wiki/GSOC_2014/Student_Application_haseeb/fedmsgsobump (not sure about the GSOC though, because it needs to be high-quality and requires quite a good knowledge&experience which students not always have - we'll see in a couple of weeks if somebody else is interested)

Owner

pypingou commented Mar 28, 2014

@dumblob the application period is over so you will not have anymore proposals for GSoC this year.

dumblob commented Mar 28, 2014

@pypingou I didn't meant "somebody" as "somebody from GSOC" - just anyone interested on his own :) (most of us don't like the painful bumps, so everybody from us should be sufficiently motivated)

tflink commented Mar 28, 2014

Well, to me it seems rather different - the tasks are quite limited (e.g. I can't imagine it to schedule revbump and rebuild) and the whole taskotron seems completely dependent on koji - i.e. this will not be usable with other rpm build systems (Copr, OBS, ...). In other words, this is not testing issue, but a rolling-release issue.

At the moment, taskotron only supports koji, yes. However, I'm not sure where you got the rest of that from.

The simple way of summing up taskotron is a system for running tasks based on input (fedmsg for the foreseeable future). One of the design goals for taskotron is to not be limited to what our old automation system was capable of. For the initial deployment/release, the tasks we're writing are limited to what used to run in AutoQA (the old system) but that's mostly a reflection of not biting off more than we can chew for an initial milestone and available resources.

dumblob commented Apr 7, 2014

Ok, but for the beginning it seems rather simpler to use just Fedmsg to keep the code base of such revbump-rebuild app as minimal as possible with as low number of dependencies as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment