GSoC 2019 [Buildbot ideas]

[Rajdeep Bharati]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190409/c98c1514/attachment.html>