That is a great vision. I'd like to help the vision with some testing and can provide you some feedback. How would you prefer the feedback? I can submit bug reports through JIRA, or send mail to the list, or some other technique.
Testing time is limited, and must be squeezed around my real job and my family, but I'm sure I can provide some testing and some feedback if there are indications they will be helpful to your efforts. Mark Waite On Mon, Mar 10, 2014 at 6:28 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I will give you my vision. > > In my vision there are two types of things: > > 1. Things that depend on the stuff in a build job itself > 2. Things that depend on the inter-relationship of jobs within a CI server. > > Traditionally, Jenkins takes the view that there is just one type of > thing. So you end up configuring everything in the Jenkins job (or you use the > evil > one<http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html> > and > have slightly less to configure) > > This leads people to want to lock down access to some portions of the > configuration... in a sense you need to let some people tweak the first > type of things (because they are changing the code being built and thus may > break the instructions as to how to build it) but you don't want to let > them tweak the second type of things (e.g. how the built application gets > put into the staging environment and which job(s) to trigger so that the > pre-production tests run against the staging environment) > > The folly people then run down is trying to get a division of permission > scopes. > > There is, however, a split... if you let people commit to source control, > then in reality you let them change the build script that lives in source > control (unless you are using SVN and lock the build script down with > permissions... but at some point a refactoring needs a tweak to the build > script and giving developers a world of pain to make those changes only > pisses them off)... or they write a unit test that does the changes on the > fly as a hack around the fact you haven't given them the ability to tweak > the build script... so now your build script is part build script part unit > test hacks that "fix" the build script. > > So the simple fact is that however you set up your build script, you have > to accept that developers will be able to change the build script. This > probably means that you have code review for changes to the build script... > not that the devs are making malicious changes... more that they are making > appropriate changes. > > In my view a CI build job should not need configuration changes to reflect > a change in the build script... the CI job should be able to pick up the > configuration relevant to the build script from the source tree itself... > hence the literate job type. > > This unlocks a lot of great power... tracking multiple branches is now > trivial, as each branch stores the detail of how that branches version of > the build script should be interpreted... > > All the Type 1 things are configuration that naturally should sit within > source control. People who can change the build script can then change the > corresponding jenkins configuration in the same atomic commit. > > The Type 2 things are about the greater context. That context relies on > other projects. It relies on knowledge that is outside the scope of SCM > about which branch is the current mainline... The SCM may know on Day X > this branch was tagged as being the mainline... but it has no way to link > against the other SCM repos that hold the side projects with their > independent release schedules. > > The Type 2 things are invariably the bits that you don't want the > developers messing with. With the literate project type those things remain > in the Jenkins UI. > > Literate (and I think it needs a better name BTW) is about moving the Type > 1 things out of the Jenkins UI and into the SCM where they belong. > > What is literate missing before I call it 1.0 (without the alpha or beta): > > * Support for GitHub pull requests > * Support for Maven multi-module reporting (without invoking the curse of > the evil one) > * Support for untrusted builds (partially there... just need something > that people can more easily use) > * It would be super nice if Vincent can get his Yaml parser stuff > committed before 1.0 also so that people who don't like the markdown build > description can use the yaml based alternative (literate has always had a > "yaml" format... just one that only supported a very very small subset of > the "yaml" syntax that people expect) > > The real joy of literate will be when you can have pull requests get their > own branch job on demand that gets built with a commit note being added > back to the pull request and the branch job being removed once the pull > request is resolved. > > The functionality comes with a risk... namely the drive-by pull request > that f*cks your build server... oh let's just add a `rm -rf /` to the build > script via a pull request using a throwaway github account I created just > to screw you over. > > So before I give people the GitHub pull request UI for literate... I need > to give people an easy route to protect themselves, e.g. by letting them > say that pull request builds will run in a chroot environment, or an LXC > container, or whatever set of protections they want. > > On top of that, weaving in the Maven support that I want to add may make > changes to the literate job type that could be problematic to migrate, so I > would like to get those features bedded down before calling something 1.0. > > So that is my vision... there is still some work left in it... but a vast > chunk has been completed... > > > On 10 March 2014 11:56, Stephen Connolly > <stephen.alan.conno...@gmail.com>wrote: > >> Like that's going to stop them... >> >> <plugin> >> <groupId>org.codehaus.mojo</groupId> >> <artifactId>exec-maven-plugin</artifactId> >> <version>1.2.1</version> >> <executions> >> <execution> >> <goals> >> <goal>exec</goal> >> </goals> >> <configuration> >> <executable>/bin/rm</executable> >> <workingDirectory>/</workingDirectory> >> <arguments> >> <argument>-rf</argument> >> <argument>/</argument> >> </arguments> >> </configuration> >> </execution> >> </executions> >> </plugin> >> >> >> >> On 10 March 2014 00:39, Christian Willman <cewi...@gmail.com> wrote: >> >>> Unfortunately it is not possible. A common suggestion is to template out >>> your specific job type, but even then, there is no authorization strategy >>> to prevent users from simply creating a new FreestyleBuild with a console >>> build step. >>> >>> Our organization has the same requirements -- we cannot allow untrusted >>> developers to run arbitrary shell commands. We've solved this by switching >>> to an external templating system (which I wrote in-house). Now developers >>> cannot create or modify *any* jobs directly through the Jenkins UI. >>> This works for us because 99% of our Java projects can be built with a >>> simple "mvn clean deploy". The oddball jobs are isolated to a >>> heavily-audited Jenkins instance. >>> >>> Another potential solution is to implement your own job types and then >>> write a custom authorization strategy which revokes access to the built-in >>> job types. But this is not maintainable and will probably require a >>> dedicated admin to babysit the implementation for the foreseeable future. >>> >>> I've searched through the source and couldn't figure out any other >>> implementations which don't require modifications to the Jenkins core. >>> Unfortunately nobody (including Cloudbees) seems interested in this use >>> case right now. >>> >>> Cheers, >>> Christian >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to jenkinsci-users+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
