I don't want to allow concurrent builds as that would swamp the hardware - running code coverage and full site builds can take hours, wheras a simple unit test takes 20 minutes.
I originally thought I couldn't get multiple different builds with literate - but I forgot I can change the name of the "README.md" file and could have 2 litterate jobs for each SCM. (although the linking of them then requires manual intervention (unless I have missed something else...) /James From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Stephen Connolly Sent: 10 March 2014 14:21 To: jenkinsci-users@googlegroups.com Subject: Re: Is it possible to have non editable execute shell for users? On 10 March 2014 14:19, Stephen Connolly <stephen.alan.conno...@gmail.com<mailto:stephen.alan.conno...@gmail.com>> wrote: At present it is manual trigger only. I am looking into adding a "automatic" trigger which will trigger if the build succeeds and a "named promotions" trigger which will trigger if the named promotion succeeds... the last one might be a join style trigger or an any style trigger or configurable as either. If you allow concurrent builds in a specific branch (not sure if I exposed that yet) then you'd not be blocked by subsequent commits. In any case, lightweight promotions not lightweight promotions, more the new SCM API that multibranch uses and hence I can expose to lightweight promotions in literate have the advantage that they ensure you are running in the GIT Hash of the original build... and by default any archived artifacts have been put back where they were found! On 10 March 2014 14:06, James Nord (jnord) <jn...@cisco.com<mailto:jn...@cisco.com>> wrote: Hi Stephen, Is there any documentation (other than source) on the lightweight promotions - my google karma is letting me down. I'm wondering if it can solve the use case where you want to run one set of commands first, then a different set of commands only if the first set passed and you want to be able to coalesce the run of the second set of commands such that you don't want to block another commit. ie. the "old style" analogy would be JobA (trigger on commit) -> JobB (trigger on JobA success) - where both use the same SCM. /James From: jenkinsci-users@googlegroups.com<mailto:jenkinsci-users@googlegroups.com> [mailto:jenkinsci-users@googlegroups.com<mailto:jenkinsci-users@googlegroups.com>] On Behalf Of Stephen Connolly Sent: 10 March 2014 12:55 To: jenkinsci-users@googlegroups.com<mailto:jenkinsci-users@googlegroups.com> Subject: Re: Is it possible to have non editable execute shell for users? 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 <mark.earl.wa...@gmail.com<mailto:mark.earl.wa...@gmail.com>> 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 <stephen.alan.conno...@gmail.com<mailto:stephen.alan.conno...@gmail.com>> 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 <mark.earl.wa...@gmail.com<mailto:mark.earl.wa...@gmail.com>> 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 <stephen.alan.conno...@gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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.
