thors/jenkins — comment on commit 085c8a6d4194e79d707f7ea75c7ede7f6ac8b37a
File:  line 0
By thors:

Hi, thanks for the feedback. In principle I agree that it is probably better to have more extension points than implementing everything in the core. But in this case (checkout handling) I can hardly imagine many more use cases, and that a shared workspace is required to reasonably use this option is well documented.

> But what if another build environment can't do concurrent writes to a shared workspace?
If someone really wants to checkout for configurations and not for parent, he will hit the same issue I fell over in my first attempt: SCM polling as a build trigger will not work. This is not obvious for anyone not familiar with jenkins internals, exposing it as an extension point might lure more people into this trap. Also this use case is not that beneficial since is saves only one instance of the repository, while the other way around it saves multiple instances (assuming that noone would configure a multi configuration project with less then two actual configurations)

> But what if another build environment can't do concurrent writes to a shared workspace?
Then the user needs to work around it (e.g. by running the builds sequentially). The feature clearly warns the user that the slaves need to share the same workspace, the implications should be clear to the user. Jenkins is a sophisticated tool for technical people, so while I would not expect the end user to have insider knowledge in Jenkins (e.g. required to understand why discarding parent checkout disrupts build trigger SCM polling), I would expect him to understand those thing not Jenkins specific.

I can try to work on extension points for this purpose, but it will surely take time. I'm neither too familiar with Jenkins, nor am I mainly a Java developer, nor do I have any experience with groovy or jelly to add the required UI options; I'm working as build/test automation engineer to support a project for multiple platforms (some embedded) and a frequently changing set of feature branches.

For now I created a new branch from my fork, thors-integration, which contains my modifications and will be re-based for new official jenkins-releases, so I will keep my patches in sync with mainline. In our company I'm using this fork now. Of course this cannot be a final solution, but it will take some time before I could start working on your proposal, and it would definitely require me to learn more about Jenkins internals, jelly and groovy. And looking at the ticket JENKINS-4960 there are some others that are waiting for such a feature as well.