Team projects have recently began at university. We're going to be assigned a real life customer, with real life issues. But the past couple weeks have just been set up, effectively self-taught tutorials on tools such as SVN, Trac, and Jenkins.
Jenkins is a pretty nice automated build tool that allows for continuous integration of software projects. We have it set up so that any time someone commits a change to the SVN repository Jenkins will checkout the code, build it, and run tests. If the build or tests fail, a notification is dispatched.
This works well for our individual teams, and would for the year if the university had set up separate Jenkins installs for each team. But nope, all teams are working on the same Jenkins instance.
That's fine, right? Jenkins has built-in support for usergroup permissions, each group just has to have permission to administrate their own project. For example, all our team members are in the Unix usergroup tp3a, so our project only allows users in that user group to edit the configuration.
Unfortunately, it appears to be slightly broken. Any member of any group can add themselves as full admins of any other groups projects.
I just hope none of my classmates feel the inclination to mess around with other peoples projects, but you know what they say: 'Anything that can happen WILL happen'.
Most Related Posts
Glasgow University Hackathon Winner 2015My team achieved first place at the Glasgow University Tech Society Hackathon of 2015! Here's a little about what we created.
Amazon Development Centre Application ExperienceIn October 2015 I applied for a Software Development Engineer Intern position at Amazon Development Centre in Edinburgh, United Kingdom. Here's my experience.
Enjoyed my post? Sign up to the newsletter to receive a small email when I post. No spam, I promise.