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 <rajdeepbharat...@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 <mo...@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