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

The main criticism I have of this implementation is that it introduces a configuration option into the core that handles a very narrow usage model: sharing the SCM checkout between a matrix parent and its child configurations, as long as they run on the same node. Skipping the SCM checkout by the matrix parent is a feature that has been asked for often. But what if another build environment can't do concurrent writes to a shared workspace? What if the other build environment wants the children to do checkouts but not the parent? How would the configuration look like if all of these had individual configuration options?

I'd like to suggest a different design: introduce a MatrixSCMCheckoutStrategy extension point. The core's existing behavior of checking out for the matrix parent and all the configurations would be the default implementation of such an extension point. Then you could create a plugin that implements this extension point, that handles your specific usage model. Other people can create other implementations that are suitable for them. The UI would have a single drop down that people can pick a checkout strategy from. (I'd add that if there was only one implementation registered, don't show the drop down at all, and use it automatically.)