I added the lightweight promotions support last month: https://github.com/jenkinsci/literate-plugin/commits/master but the next set of things are stuff that happens in other plugins... so in a sense some of that is not visible until I think it is ready to show ;-)
On 10 March 2014 12:46, Mark Waite <[email protected]> wrote: > 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. > -- 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.
