User rights in Hudson - what I really need

When Hudson first came out, it had only the most basic user authentication schema. Administrators could do everything, and everyone else could only sit and watch.

Well Hudson has come along way since those days, and in the more recent versions, we are starting to see an interest role-based authentication schema. As well as using Hudson's own built-in user database, you also can delegate authentification to the servlet container (say, Tomcat) or to an LDAP server. And, using a recently-introduced feature called "Matrix-based security", you can basically configure which users have what permissions in a big table. You can define permissions either for individual users, or for groups (or roles).

This is cool, but actually, what I really need sometimes is per-project (or per-job) user rights. For example, a developer should be able to force a build on the integration server, but only QA staff (or the project manager, or whoever) should be able to trigger off a build that deploys a new version onto the QA server.

Some of the commercial CI tools do this nicely. TeamCity comes to mind, as does (I think) Bamboo. Maybe Hudson will let you do this in next week's release ;-).

By the way, Hudson is currently leading in the 2008 CI Servers poll, followed by CruiseControl and TeamCity.

John is a freelance consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Wellington, New Zealand. Well known in the Java community for his many published articles, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in open source technologies, SDLC tools, and agile development processes. John is principal consultant at Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website.