On 12/04/2016 05:47 PM, Michał Górny wrote: > On Sun, 4 Dec 2016 16:58:26 +0000 > Markos Chandras <hwoar...@gentoo.org> wrote: > >> On 12/03/2016 05:31 PM, Michał Górny wrote: >>> On Sat, 3 Dec 2016 13:13:36 +0000 >>> Markos Chandras <hwoar...@gentoo.org> wrote: >>> >>>> On 12/03/2016 10:41 AM, Michał Górny wrote: >>>>> On Sat, 3 Dec 2016 10:35:32 +0100 >>>>> Patrice Clement <monsie...@gentoo.org> wrote: >>>>> >>>>>> Friday 02 Dec 2016 14:10:27, Michał Górny wrote : >>>>>>> Hi, everyone. >>>>>>> >>>>>>> I've heard multiple times about various tinderbox projects being >>>>>>> started by individuals in Gentoo. In fact, so many different projects >>>>>>> that I've forgotten who was working on most of them. >>>>>>> >>>>>>> I know that Toralf is doing tinderboxing for most of the stuff. >>>>>>> What other projects do we have there? What is their status? >>>>>>> >>>>>>> Is there anything we could try to integrate with pull requests to get >>>>>>> a better testing? >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Michał Górny >>>>>>> <http://dev.gentoo.org/~mgorny/> >>>>>> >>>>>> Continuous integration is all the rage these days and tinderboxing is the >>>>>> obvious way to go concerning Gentoo. AFAIK, Toralf is the only >>>>>> contributor >>>>>> doing tinderboxing out of his own will. In reality, we should have a >>>>>> team of >>>>>> devs looking after our own tinderboxes instead of relying on the >>>>>> community. >>>>>> >>>>>> I'm wondering if we could start a donation campain for this project and >>>>>> ask >>>>>> people if they've got spare machines laying around. I know a lot of >>>>>> folks are >>>>>> reading this mailing list so maybe asking on gentoo-dev first for a >>>>>> start would >>>>>> be appropriate. >>>>> >>>>> Hardware is not the problem. Lack of software is. >>>>> >>>> >>>> Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do >>>> instead of reinventing the wheel? >>>> >>>> [1] http://open.qa/ >>>> [2] https://openqa.opensuse.org/ >>>> [3] https://openqa.fedoraproject.org/ >>> >>> Do you by any chance happen to know how it maps to our needs? >>> At a first glance it seems quite tangential. >>> >> >> Depends on what you want to test. I guess openQA would be a very good >> solution if you want to test a snapshot of the tree against the most >> common scenarios for example >> >> - todays snapshot with plasma5 >> - todays snapshot with gnome3 >> - todays snapsnot with lxqt >> - ... >> - todays snapshot with a few tests against popular console packages >> * can gcc build small C test files? >> * does bash work? >> * does coreutils popular tools work as expected? >> >> >> Having such scenarios in place is probably a more realistic testing >> approach than simply build everything with random USE flags just for the >> sake of build coverage. > > I'm looking for something I could tell 'build this package on this > commit (pull request)', optionally with some USE flags adjustment. > And I'd like it to be fast, i.e. don't bother rebuilding whole KDE > libraries every time a pull request requiring them is updated. >
I think that both approaches are valuable then. We may need different set of software solutions though. Wouldn't, for example, Jenkins or buildbot do what you want on the per-package PR testing? And then you could use openQA to test the entire tree as a whole. -- Regards, Markos Chandras
