Thanks James, thats an interesting path, but it does look like we would have to build quite a lot around this to make it a good replacement of our current infrastructure. We also did have a look at jenkins-x, but to be honest, it is just way to much for us: first of all we don’t use k8s (we use cloud foundry) and I would say that running jenkins-x cost us more then our production environment, because of the number of pods (yes, we don’t have a micro service architecture) /Domi
> On 30 Nov 2018, at 15:02, James Strachan <jstrac...@cloudbees.com> wrote: > > we solved this in Jenkins X through the use of Prow for handling webhooks & > orchestrating the serverless jenkins pod and then using kubernetes custom > resources to maintain state (pipeline activities, environments, teams, > releases etc) > https://jenkins-x.io/news/serverless-jenkins/ > <https://jenkins-x.io/news/serverless-jenkins/> > > we then use an immutable docker image of jenkins that starts up (thanks to > the custom war packager) and processes each pipeline execution in a separate > container. > > > On Fri, Nov 30, 2018 at 1:51 PM domi <d...@fortysix.ch > <mailto:d...@fortysix.ch>> wrote: > Hi, > > Since we now have JCasC and the job-dsl plugin it is easier then ever to > treat jenkins as a disposable resource and just recreate it from scratch > whenever you feel the need for it. > We do have build everything around this idea and reinstall our whole build > infrastructure every time we need to update jenkins or even just a plugin (we > create a docker image with all required plugins preinstalled). > > But there are two issues which hurt us quite a bit: > > 1. Pipeline jobs do not listen on any commit webhooks before the job was not > executed at least once (in our case Bitbucket, but the same is true for > Github) > 2. A multi branch pipeline (organizationFolder, *-branch-source-plugin) job > will trigger a build for every single branch just discovered. This is quite a > problem in case you have build your processes around git (some call it > GitOps). e.g. if every time your master branch gets build something special > happens: build a new release version of a library or even install something > to some environment. > > These two issues together cause us quite some problem, because every time we > setup a new environment the following happens: > > The branch source plugin (in our case Bitbucket) scans the whole organisation > for branches, will trigger builds and therefore: new releases of libraries > and artefacts get build and some stuff gets installed because the builds for > many of our ‘master’ branches are triggered too. > Then I somehow have to trigger a build for all other pipelines (not managed > by the branch-source-plugin) which should listen on any git webhooks, because > otherwise they will never be triggered > > > Does anyone have the same experience? How do you work around them? > > I have some ideas on how to solve/ workaround it: > - problem 1: write a plugin which is able to abort the build in case it is > the first run and the job is configured to listen on webhooks (e.g. Bitbucket > or GitHub), then after installing the fresh environment, just loop through > all jobs (with groovy) and trigger all which have a hook configured and let > the first run fail on purpose. > - problem 2: extends > https://github.com/jenkinsci/basic-branch-build-strategies-plugin > <https://github.com/jenkinsci/basic-branch-build-strategies-plugin> to some > how skip some branches at the initial organisation scanning, I already > created an issue for this: https://issues.jenkins-ci.org/browse/JENKINS-54861 > <https://issues.jenkins-ci.org/browse/JENKINS-54861> > > But to be very honest, most of this sound some how hackisch and I hope > someone else has a better idea on how to do this stuff properly. > > Many thanks > Domi > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-dev+unsubscr...@googlegroups.com > <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/FA18D443-D4CA-4512-BAD1-255D6E3385C8%40fortysix.ch > > <https://groups.google.com/d/msgid/jenkinsci-dev/FA18D443-D4CA-4512-BAD1-255D6E3385C8%40fortysix.ch>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > James > ------- > Twitter: @jstrachan > Blog: https://medium.com/@jstrachan/ <https://medium.com/@jstrachan/> > > Jenkins X: a CI/CD solution for modern cloud applications on Kubernetes > http://jenkins-x.io/ <http://jenkins-x.io/> > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-dev+unsubscr...@googlegroups.com > <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CALvxejm05axySHoqVEGrvX%3DrCPj4a4EfK3Q39oqDLrMwjrT-hQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CALvxejm05axySHoqVEGrvX%3DrCPj4a4EfK3Q39oqDLrMwjrT-hQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9B0B05A3-E884-419F-B85E-471F22B66AC6%40fortysix.ch. For more options, visit https://groups.google.com/d/optout.
