On 26 November 2016 at 15:45, Gary Gregory <garydgreg...@gmail.com> wrote: > That sounds even more complicated to deal with :-( I would have to fiddle > with branches just to make a Jenkins build change? Is there a precedent for > such a set up?
Huh? Surely the Jenkins setup script is independent of the build. The precedent is that Jenkins is independently set up manually at present; AIUI the difference is that one would use a script in SVN/Git instead. I assume this would only have to be done when the script changed or when you wanted to set up a new build. This is akin to running the Commons Build plugin. That is in a separate part of the repo, but that makes it *less* complicated. Imagine what it would be like if every branch had its own (slightly different) copy... > I do like the idea of having the Jenkins build file right there like Travis > CI but it is slightly worrisome that we have more files to keep in sync. > Nothing to do except proposing a POM based standard. > > The nice thing about .travis.yml is that it is simple for plain cases like > for most Commons components. > > Gary > > On Nov 26, 2016 3:19 AM, "sebb" <seb...@gmail.com> wrote: > >> Seems OK to me. >> >> However I think the script should be added to its own separate SVN/Git >> branch (not trunk/master). >> It's not a part of the source release per se, and as you write, it can >> be applied to multiple branches. >> Having it in the main source trees would be confusing, and more copies >> to merge when updates are needed. >> >> On 26 November 2016 at 10:18, Benedikt Ritter <brit...@apache.org> wrote: >> > Hello, >> > >> > currently we define our Jenkins job through the Jenkins UI. The problem >> > with this is, that there is no connection between the source code and the >> > way it is build. The Build job configuration is versioned separately from >> > the source code in Jenkins it self. >> > >> > With the Jenkins Pipeline Plugin [1] it is possible to define Jenkins >> Jobs >> > in the source repository using a (groovy based) Job DSL [2]. So rather >> than >> > clicking through the Jenkins UI, one just writes down what jenkins should >> > to and checks it into version control. >> > >> > The cool part is, that jenkins is than able to recreate the build >> pipeline >> > for every branch. This comes in handy when working with a gitflow like >> > development process, where there are several branches being changed. >> > >> > I'd like to setup a PoC for the Commons Lang project showing, how this >> > looks like in real life. The PoC can than be adopted by other components, >> > if they wish. >> > >> > Please let me know if you have objections. >> > >> > Regards, >> > Benedikt >> > >> > [1] https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin >> > [2] https://jenkins.io/solutions/pipeline/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org