domi
2018-11-30 13:51:04 UTC
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 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
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
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 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
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+***@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.
For more options, visit 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+***@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.
For more options, visit https://groups.google.com/d/optout.