![[Buildbot Logo]](/chrome/site/header-text-transparent.png)
| Version 46 (modified by dustin, 3 years ago) (diff) |
|---|
Table of Contents
If you're interested in working on any of these ideas, or have ideas of your own that you'd like to work on, get in touch! See the links on Development, or email the project development mailing list.
GSoC 2016
The projects on this page are, of course, open to anyone who wants to contribute, but the page is designed specifically for potential Google Summer of Code students. Keep in mind that we have three goals for GSoC:
- We gain new contributors to Buildbot
- You learn about open-source development by doing it
- Users get amazing new Buildbot features
We'd like to achieve all three goals, but the world is messy, and predictions are hard. If you finish the summer having learned a lot and become a lifelong contributor to Buildbot, but without wrapping up a user-visible feature, that's still OK.
Applications should follow the form given in GsocApplicationTemplate.
Open Ideas
| Ticket | Summary | Owner |
|---|---|---|
| #896 | Replace try with a client for the force scheduler | verm |
| Description |
We have a "try" client defined which looks for a patch in a local repository on a developer's system, patches it up, and submits it to Buildbot. It's very ad-hoc, isn't very configurable, and hasn't gotten a lot of love. Now that we have a force scheduler, the better solution is for the try client to talk to a force scheduler, preferably using HTTP. The client should also capture and send e-mail address of the submitter so that notifications can be sent. This allows lots of flexibility on the master side: users can set up as many force schedulers as they like, with different builders, properties, permissions, and so on. scopeTo make this project a summer's worth, it should aim to implement:
|
|
| #1788 | MQ options | |
| Description |
When Buildbot adopts an MQ framework, there are a number of choices. Among them:
The first is already implemented in 'nine', but we need more. The more difficult part of this project is to ensure that messages are only delivered after the corresponding database changes are visible. The issue is a race condition between message passing and database replication. Imagine you have a large Buildbot installation with several replicated MySQL servers and a redundant RabbitMQ cluster. One buildbot master writes changes to a build to the database (an UPDATE operation), then sends a message describing the change. On another master, some service gets the message and queries a different MySQL server to see the build's new status. If the message arrives before the database replication occurs, then this master will see stale data. That will lead to a lot of subtle, rare bugs. scopeThis project would involve separate tasks:
relevant bugs
|
|
| #2044 | Make buildbot high-scores board | |
| Description |
The idea is to have a web application which aggregates various buildbot activity into one place and assigns a total score to each contributor. It should be a fun way to motivate contributors and help them to compare their level of effort with others. This would not be a part of the Buildbot application, but a separate service written and maintained by the Buildbot developers. refs: Related: |
|
| #2438 | Windows Process Management | |
| Description |
The windows tag documents a number of bugs about starting and killing processes on Windows. Buildbot uses Twisted's process-handling code, so these bugs may be fixed by either re-implementing better support directly in Buildbot, or by patching Twisted's process-handling code. See also: ScopeTo do well with this project, you would need to bring a lot of the Windows experience that is lacking in the Buildbot development community. Assuming you're familiar with Windows APIs and accessing them from Python, this bug would entail
Related Bugs
|
|
| #2590 | Use Alembic instead of SQLAlchemy-Migrate | |
| Description |
Migrate has some compatibility problems - in particular, it doesn't work with SQLAlchemy >= 8.0. Its API is a little unpredictable, too, and it doesn't do a very good job of masking differences between dialects. Its linear numbering scheme is also problematic when developing on topic branches, as a merge of branches with overlapping DB version numbers will need some substantial changes to put them in linear order. Alembic seems to be the fix to all that, although that's as far as we've gotten. This would make a decent, if small, Google Summer of Code project. ScopeThe goal of this project is clear: replace the functionality of SQLAlchemy-Migrate with equivalent functionality implemented with Alembic. A GSoC application should also address:
|
|
| #2649 | i18n -- Internationalization | |
| Description |
The Web UI should be localized. AngularJS ecosystem has ngTranslate project, which makes i18n relatively easy. scopeThis project would require
|
|
| #2692 | Auto-generate some documentation | |
| Description |
Lots of the Buildbot documentation is manually maintained to correspond to the code: buildstep arguments, data API descriptions, DB APIs, and so on. It'd be great to have some means of automatically verifying or even generating that documentation. http://dexy.it/ looks like a useful general tool for building this kind of thing. ScopeThis project would involve writing code and configuration to automate the documentation-generation process. This should take Buildbot's source code as input (preferably parsed by Python, rather than with regular expressions or some other text-mode process) and generate rst output that can then be processed using Sphinx. A good GSoC application will identify several areas of the documentation that can be converted to automatic generation. These should become milestones in the project schedule. |
|
| #2966 | New web plugin idea: a health indicator | |
| Description |
I like to extract as much useful indicator from my builds as possible (time, but also amount of warnings, and such ...) It would be cool to have a web plugin that could print the evolution of my indicators over time ! (Of course, I would have to configure which indicator I want to see plotted, maybe the kind of plot, and so on ...) |
|
| #3147 | [AngularJS project] Use angular dashboard framework for nine homepage | |
| Description |
Angular dashboard framework provides nice user interface for letting the user customize their homepage. show page of this project: http://sdorra.github.io/angular-dashboard-framework It is compatible with the boostrap CSS framework that we are based on, and has a nice api for defining new widgets. This project is about integrating this framework in buildbot, and creating a few widgets. Example widgets could be:
|
|
| #3148 | [AngularJS project] Optimised communication between backend and frontend | tothandras |
| Description |
Communication between backend and frontend is a tricky problem. Web browser must get the current state of an object, and then register to a message queue to automatically update its internal model. A good prior art for such system is firebase: https://www.firebase.com/docs/ Buildbot nine implement similar ideas in buildbotServices, but has a number of bottlenecks.
Student will analyse current implement implementation, and propose changes to address those issues. Probably a full rewrite will be necessary. |
|
| #3452 | [AngularJS Project] Add E2E tests | |
| Description |
We need some capability to run end-to-end tests of the AngularJS frontend to avoid UI regressions and other issues that are not obvious in unit tests. This should be done with the normal angularJS methodology, with protractor: https://docs.angularjs.org/guide/e2e-testing What is necessary for e2e tests is:
The idea should be to hook up the tests in the metabuildbot, and allow motivated developers to run them manually, but they need not be as easy to run as 'trial buildbot.test'. Documentation on what are the steps to run that (probably easiest is to setup the deps in a dockerfile) |
|
| #3453 | [AngularJS Project] Improve AngularJS unit testing framework | |
| Description |
The unit tests for Buildbot's Angular components need to be expanded. That means more tests, but it also means more support code for those tests. In particular, a realistic means of simulating the Buildbot server backend. Ideally that would be a fake backend, and one that is guaranteed to match the real thing by use of RAML or JSON-Schema or similar API-description techniques. This project would involve picking the API-description technique, applying it in the Python code, and then writing the fake backend in CoffeeScript. And writing tests that use the backend, to show that it works. There are other options here -- perhaps running the Buildbot master in a "test backend" mode that allows extra API calls. The end result should be a way to realistically test Angular components against the Buildbot Data API. |
|
| #2890 | Improve support for Gerrit | |
| Description |
There's a number of things that could be improved for Gerrit support. (And I'd need to create a ticket for this particular problem: force the version (if an installation is prepared incorrectly, Gerrit fails to report its version: might fail certain actions).) List of relevant tickets
defect type tickets:
enhancement type tickets:
project-idea type tickets:
support-request type tickets:
|
|
Your Idea Here!
We are open to any ideas that will make Buildbot better - think of this page as a set of ideas to get you started.