GSoC 2019 [Buildbot ideas]

Pierre Tardy tardyp at gmail.com
Mon Apr 8 20:13:58 UTC 2019


A javascript library which you can simply call from your main.js and
which will implement all the boilerplate needed to connect your vue
component to the angularjs application

Regards
Pierre

Le lun. 8 avr. 2019 à 21:23, Rajdeep Bharati
<rajdeepbharati13 at gmail.com> a écrit :
>
> Hi Pierre,
>
> By library do you mean a library of components and JSON interfaces?
>
> Regards
> Rajdeep
>
> On Tue, Apr 9, 2019 at 12:18 AM Pierre Tardy <tardyp at gmail.com> wrote:
>>
>> 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


More information about the macports-dev mailing list