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.
Rajdeep On Sun, Apr 7, 2019 at 6:17 PM Rajdeep Bharati <rajdeepbharat...@gmail.com> wrote: > I was attempting to package the plugin. > A possible workflow may be: > > - The user would install the package in something like a vue-cli or > create-react-app. > - Write the component > - Pass that component to the `link` function of the plugin. > - There would be options to customize the settings(limit, order, > adding other props, etc) (or even write the whole link function themselves) > > One problem that I am facing is getting the angular dependency inside the > vue/react app which is utilizing the npm package(plugin). Here's the code: > https://github.com/rajdeepbharati/buildbot-vue-plugin-boilerplate/tree/plugin > > Thank you. > Rajdeep > > On Sat, Apr 6, 2019 at 9:05 PM Rajdeep Bharati <rajdeepbharat...@gmail.com> > wrote: > >> Thanks for the feedback! >> >> On Sat, Apr 6, 2019 at 7:03 PM Mojca Miklavec <mo...@macports.org> wrote: >> >>> Dear Rajdeep, >>> >>> On Sat, 6 Apr 2019 at 13:33, Rajdeep Bharati wrote: >>> > >>> > I was wondering what kind of features you would like to have in the >>> new waterfall view? >>> >>> I don't remember whether I ever explicitly said I wanted some new >>> features there :) >>> >>> Probably the only thing I really miss is the portname explicitly seen >>> without having to click (or mouse-over) the rectangle. >>> >>> Way less important: >>> - in case the build failed, it would be nice to see which step (first) >>> failed, again without having to move the mouse around >>> - in case the build is still running, see which step is running (I >>> would also say "time since start" or "estimated time to finish", but I >>> don't want a ticking timebomb that keeps changing every second, so you >>> may safely ignore this) >>> >>> Generally the old waterfall had all the necessary info displayed. The >>> new one is more compact (I would also say not too attractive design, >>> but I'm not someone to judge that as I'm not a designer), but is >>> basically lacking all the info. If one builds the same thing under the >>> same builder that might be fine, but we build something else each time >>> and without knowing what was built, those green and red squares are >>> basically useless. >>> >>> >>> Some more ideas for thinking. One of the most desperately needed >>> features to make buildbot views usable for anything else than "what's >>> currently being built" would be to sort (filter) by port name. >>> >>> Now, port name is something specific to MacPorts, but we could >>> probably introduce filtering by any kind of keywords. We could write >>> to our master.cfg that we want to create a new filter with name "port" >>> and then each port would get a keyword matching its name. Then I could >>> ask buildbot to display me history of all builds of port "clang-7.0". >>> But then a few months later we might realize that we want to display >>> all the failed builds from a particular maintainer. Maintainer is >>> again something specific to MacPorts, but we could simply introduce a >>> new category "maintainer" on the fly and use the github handles as >>> keywords to search for, and I could ask buildbot to display me all >>> broken builds belonging to maintainer "mojca" without any changes in >>> the buildbot or the view itself, just by slight modification in >>> master.cfg. One year later we could add an arbitrary new category that >>> we have never even thought of, and be able to filter according to that >>> one (maybe: show me all builds of python or perl modules; show me all >>> builds with non-free licence; show me all builds from ports fetching >>> from git, ...). Those categories could potentially be nested. >>> >>> Mojca >>> >>