You can change the name of the section that is considered the build section ;-) it just *defaults* to "build"
On 10 March 2014 14:41, James Nord (jnord) <[email protected]> wrote: > 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:* [email protected] [mailto: > [email protected]] *On Behalf Of *Stephen Connolly > *Sent:* 10 March 2014 14:21 > > *To:* [email protected] > *Subject:* Re: Is it possible to have non editable execute shell for > users? > > > > > > > > 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. > > -- > 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.
