GSoC 2019 [Buildbot ideas]

[Rajdeep Bharati]

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 <rajdeepbharati13 at gmail.com>
wrote:

> Thanks for the feedback!
>
> On Sat, Apr 6, 2019 at 7:03 PM Mojca Miklavec <mojca at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190407/ea350bdd/attachment-0001.html>