On 10 March 2014 14:19, Stephen Connolly <[email protected]>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) <[email protected]> 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:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Stephen Connolly >> *Sent:* 10 March 2014 12:55 >> *To:* [email protected] >> *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 <[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. >> >> -- >> 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.
