Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Markos Chandras]

On 12/04/2016 05:47 PM, Michał Górny wrote:
> On Sun, 4 Dec 2016 16:58:26 +0000
> Markos Chandras <hwoarang@g.o> wrote:
>
>> On 12/03/2016 05:31 PM, Michał Górny wrote:
>>> On Sat, 3 Dec 2016 13:13:36 +0000
>>> Markos Chandras <hwoarang@g.o> wrote:
>>>
>>>> On 12/03/2016 10:41 AM, Michał Górny wrote:
>>>>> On Sat, 3 Dec 2016 10:35:32 +0100
>>>>> Patrice Clement <monsieurp@g.o> 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