GSoC 2019 [Buildbot ideas]

[Pierre Tardy]

Hi Rajdeep,

We already have a yeoman generator:
https://github.com/buildbot/guanlecoja/tree/master/generator-guanlecoja

I think the current boilerplate has more than just boilerplate.
It also has some code that could be factorized.
It is better not to put too much in a generator, as it is hard to
upgrade after a first instanciation
So I would recommend a generator plus a library.

Regards
Pierre
Pierre

Le lun. 8 avr. 2019 à 18:44, Rajdeep Bharati
<rajdeepbharati13 at gmail.com> a écrit :
>
> @Mojca Miklavec Oh, I see.
>
> @Pierre Tardy Regarding the npm package: I think it would be better to create a project generator CLI (which would create the boilerplate project, similar to vue-cli or create-react-app). Do you think that would work? Can I use yeoman to do this?
>
> Thank you for help.
> Rajdeep
>
> On Mon, Apr 8, 2019 at 7:05 PM Mojca Miklavec <mojca at macports.org> wrote:
>>
>> Dear Rajdeep,
>>
>> On Sun, 7 Apr 2019 at 19:41, Rajdeep Bharati wrote:
>> >
>> > I found something which might help us: https://bors.tech/homu-io/ https://github.com/barosl/homu.
>> > I will try it set it up on my local system and get back to you.
>> > Mojca
>>
>> This sounds nice, but I wonder if it would actually address any of our
>> problems (I suspect not). Also, it explicitly says that the project
>> was kind of abandoned and continued elsewhere?
>>
>> What this tool is trying to solve is to check the code again after
>> potentially long code review process, and run CI again "just before
>> merging". However some of our builds would take hours, or, well, on
>> Travis you might get 2 hours of waiting time and then one hour of
>> building, just to experience a timeout at the end anyway. This makes
>> the "just before merging" kind of not-too-well-defined. Plus, half of
>> our Travis failures are false negatives, and before this can be useful
>> on the buildbot, we would need to be able to enable checking pull
>> requests in a "safe way" (addendum: for such checking we could
>> probably just as well engage a couple of machines which are completely
>> decoupled from our main builders, which would run, say, just 10.5,
>> 10.6, 10.9, and would not upload the results anywhere). When checking
>> the base ... we have so little activity that this is practically never
>> an issue. And with ports there are so many distinct ports, that this
>> is also hardly ever an issue; and when it is, you would already notice
>> that the PR cannot be merged.
>>
>> Mojca