| 55 | | = User Objects = |
| 56 | | Owner: verm |
| 57 | | |
| 58 | | Buildbot deals with "users" in a number of ways: commits are generated by users, and those cause builds that the users may want to know about. Users can also cause builds via the web, IRC, or from command-line tools. Buildbot communicates results back to people through a number of mechanisms, too: email, IRC, web, and so on. In many cases, Buildbot administrators need to ensure that only certain people can perform certain operations, such as starting or cancelling builds. |
| 59 | | |
| 60 | | The project, then, is to design and implement a consistent way to represent "users" throughout Buildbot. |
| 61 | | |
| 62 | | == Scope == |
| 63 | | This project has a significant design component, since there is very little code related to users in Buildbot right now. The design would need to address backward compatibility (users should not have to change their buildbot configurations when upgrading), security, flexibility (we have almost a dozen version control backends, and each thinks about users differently!), and configurability. There will most likely be a new database table or two to add. |
| 64 | | |
| 65 | | Once the design is done, this project should have a few concrete milestones where particular parts of Buildbot start using the new functionality. For example, when MailNotifier can use the new functionality to translate the author of a source-code commit into an email address, that is a concrete milestone. |
| 66 | | |
| 67 | | ---- |
| 81 | 69 | * Source managers that know everything about a particular version control repository. A source manager, for example, could determine the changes that were made between two source stamps (revisions), or provide the information required to check out a particular revision from a repository. Source managers, too, could be implemented for a single version control system, so that others can finish the work for the remaining systems. |
| 82 | 70 | * "Gaggles" of builds. Right now, it is very difficult to wait for a number of different builds to finish - for example, if you need the Windows and Linux builds to finish so that you can compress them into a CD image. The most difficult part is to determine when two builds "go together", even if they occur at different times. If we can group builds into gaggles, then it's easy to wait for, for example, all of the Linux and Windows builds in a particular gaggle to finish before starting the CD-burning build. This project would involve a lot of design discussions with Buildbot users, then some database and code changes to manage gaggle identifiers. Finally, some easy-to-use synchronization steps and documentation of how to use them would make this available to Buildbot's users. |
| 83 | | |
| 84 | | ---- |
| 85 | | = Consistent, Efficient Source Steps = |
| 86 | | Owner: djmitche or tomprince |
| 87 | | |
| 88 | | Slaves often checkout/clone the entire repo (when doing full builds). This can take a lot of time and network traffic, and often takes *more* time with the new distributed version-control systems, since they like to download the entire history for each clone. There are a few "modes" defined which try to reduce this need (e.g., by copying an untouched checkout, or trying to "clean" the build artifacts out of a checkout), but these are implemented inconsistently across version control systems. They also do not take full advantage of the capabilities of all of the version control systems. For example, it may be possible to do a "shallow" clone that does not pull in unnecessary history; some version control systems support a cache of some sort that can store history that might be common across multiple builds on the same slave. |
| 89 | | |
| 90 | | Buildbot needs a consistent, easy, and configurable way for users to take advantage of these behaviors. |
| 91 | | |
| 92 | | See also |
| 93 | | * http://trac.buildbot.net/ticket/669 |
| 94 | | |
| 95 | | === Scope === |
| 96 | | This project begins with a significant design problem: figure out the common behaviors across a number of version control systems, and how to represent those behaviors to Buildbot's users. Once that's done, you'll need to implement those new behaviors. To allow for different amounts of available time over the summer, it will be smart to start with one version-control system, then tackle more if time allows. |
| 97 | | |
| 98 | | ---- |
| 99 | | = Master-Side Source Steps = |
| 100 | | Owner: djmitche or maruel or tomprince |
| 101 | | |
| 102 | | Buildbot currently implements a lot of the "smarts" of its source-checkout steps on the slave. That makes it hard to configure and change that behavior, since generally Buildbot users have one master a lot of slaves. Ideally, the slaves would just provide functions like "create this file", "run this command", and so on, and the smarts would all reside on the master, built using the slave functions. |
| 103 | | |
| 104 | | == Scope == |
| 105 | | This is an ongoing project, so a good proposal will carve out a smaller portion of it to work on. If you choose your steps wisely, you can make small improvements to Buildbot so that if you don't finish the whole project, all is not lost. For example, you could add some more slave-side commands that aren't available yet, and then begin using those to implement just one of the source steps on the master. Your work would then provide an example for others to implement the other steps on the master. |
![[Buildbot Logo]](/chrome/site/header-text-transparent.png)