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 >> >
