Knowing that your time is limited on literate is actually a comfort. I read your earlier blog entry and thought it was a great idea, but then didn't see any further progress so I worried that the idea had died quietly. If it is still your vision but with limited time, then I'll explore and report what I find.
On Mon, Mar 10, 2014 at 6:42 AM, Stephen Connolly < [email protected]> wrote: > JIRA. That way others can help try and fix. My time on literate is limited > right now too though... so that is an issue. > > Glad you like my vision! > > > On 10 March 2014 12:33, Mark Waite <[email protected]> wrote: > >> 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. >> > > -- > 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.
