+1, very insightful. We also plan giving a try to the literate plugin in the upcoming weeks. So we're also interested to have up-to-date informations about where/how to report things, etc.
Cheers 2014-03-10 13:33 GMT+01:00 Mark Waite <[email protected]>: > 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 < > [email protected]> 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 <[email protected] >> > 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 <[email protected]> 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 [email protected]. >>>> 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 [email protected]. >> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
