Magrit wants to be a next-gen CI system. Distributed, lightweight, zero-conf, zero-infra.

The goals are:

• increase confidence of developer about their codebase
• scale team as developers join
• speed up the build, even for local-only use
• let the team decide how to use : non-intrusive system

It's using git, and only require a valid git aware system (with bash and posix tools).

zero-conf zero-infra:

• setup is supposed to be as simple as dowloading an installer and passing an url to it to join a project
• your computer is one node of the grid - the build system grows up with the project (you'll still be able to setup magrit on headless nodes like servers or cloud PaaS).

Affero GPL v3

Be clean before sharing code This is the first step for code quality : ensure that your commit won't break the build. You're used to it, but it's easy to miss things. For instance, I'm pretty sure you trigger a build before push ; but in a DVCS world, you rarely push 1 single commit. So to be really clean, you could want to test all your commits. So this is the first use case: trigger as many builds as needed.

You now got a clean view about your changes and you decide to share those with a git push.

Let switch to another developer's point of view. One of your buddies have pushed a massive bunch of commits. And you know him so well that you're pretty sure there are some dirty commits in it.

This is the second use case : decide which 'alien' commits to integrate in your local branches or not. With Magrit, you got a snapshot of all commits, even those that come from other developers because Magrit instances can share build results. Enjoy git architecture with their SHA1 commit unicity and you got a stable codebase.

If the build status are missing in the database (what a shame! someone pushed code without building them!!) you can still trigger builds for new commits of the remote branch and get a good level of confidence.

Then you're ready to pick them or leave them. Magrit can also automatize this by choosing which commit to pick or not. Classic strategy is to pick the longest chain of stable commits and to rebase your branch onto them. A good practice will be to trigger a fresh build for your branch HEAD because rebasing code doesn't always work fine. (but I'm sure you know what I'm talking about ;)).

The third use case is to distribute builds among the set of developers desktop/laptop. If you ask to build all commits for your local branch, this can involve lots of commits (I'm talking about dozens in worst cases). And if your build average time last minutes long, you could be waiting for hours to get a status. With Magrit, you can share the commits (with git magic) between developers hosts, and trigger build on these instances. By default, commits are thrown whatever happens, but you can decide to be pessimistic: send them in logic order (from parent to the HEAD) and halt them if a build fails. This strategy will be less resource greedy while still providing a good status.

And whatever happens, if a commit is stable, it will stay stable as long as it exists. There is no use to build this again because SHA1 unicity ensures code unicity and build stability. Git Magic!

There are many other features to build on this ; if you got ideas, you can use the github bugtracker.

• Show the state of HEAD:

• See the log of builds (git log like command):

You can beta test this on you projects! This is the very thing I'm currently needing. Beside, the project isn't feature complete regarding this enthusiastic document, so be patient. Your voice can make a difference and help me prioritize open features.

This is still an incubating project, so I'm not able to let developers join for the moment. But you can submit feature requests through the github bugtracker or tweet me @ptit_fred.

For french people, there is a poll to be a registered beta tester (english version coming soon): Si vous souhaitez participer, sachez que je suis à la recherche de béta testeurs. Pour vous manifester, vous pouvez répondre à ce formulaire : https://docs.google.com/spreadsheet/viewform?formkey=dEV1RXp5T2M5b2VWT0ZqdFNjSzA2SWc6MQ