[JENKINS-7192] Use multiple SCM sources

[timja]

We have certain projects that pull modules from both CVS and SVN. The way we do it right now it to pull from SVN using the plugin, and then use the "Execute Shell" to pull from CVS using the command line. It would be awesome if we could use both (may be change the radio buttons to a check boxes?) for the same project.

---

Originally reported by khushsk, imported from: Use multiple SCM sources

• status: Reopened
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

rancidfishbreath:

This would be a really useful feature. If you use any other way than through a SCM plugin (execute shell, ant, etc) you lose the ability to poll the SCM to trigger a build. Certain SCM plugins (such as Mercurial) do not support multiple repositories. Specifically the Mercurial plugin maintainers suggest that this should be part of the core part of Hudson and will not support multiple repositories. I think this makes sense since supporting multiple repositories either is supported by Hudson or duplicated in every SCM plugin.

[timja]

kutzi:

See https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin

[timja]

aaron:

+1 would be nice to have in core. need this for Git + SVN

[timja]

oleg_nenashev:

Multiple SCMs Plugin resolves the case

[timja]

danielbeck:

Oleg: Multiple SCM Plugin looks a bit like a hack. An overhaul of the core SCM api (including real support for multi-module checkouts in repo browsers) might be a good idea.

That being said, I've not used it in production – how well does it really work?

[timja]

oleg_nenashev:

It works... eventually

Actually, the behavior depends on the plugin, because the current version does not support the "newInstance" method (see https://github.com/jenkinsci/multiple-scms-plugin/pull/4). Other basic checkout & polling methods work well, but I'm almost sure that there're many bugs for more complex cases (like workspace cleanup hooks or various ItemListeners). In general, the plugin stills a hack.

I confirm that the plugin works for Subversion, Perforce (fixed in the latest version), FileSCM and Git (for primitive configurations). BTW, the plugin requires the accurate configuration. Otherwise, there's a high risk of workspace collisions.

[timja]

rodrigc:

I use Multiple SCMs plugin quite a bit. It has limitations as Oleg has pointed out, but for most simple cases
it works well enough.

A lot of the Jenkins developers are recommending using the new Workflow plugin to check out code from multiple repositories.
I haven't tried Workflow yet, but that might be an option to consider.

[timja]

greenscar:

How can you close this ticket when the multi-scm plugin clearly states: "This plugin is more of a proof-of-concept than a robust and fully functional component. It does work in my particular build environment, and is meant to serve as a demonstration of what might be possible with more work. It was inspired by JENKINS-7155 requesting multiple repository checkouts for Mercurial similar to what is possible with the Subversion plugin. It's currently implemented as a plugin, but if enough people find it useful, I think the idea would work better in the Jenkins core."? - https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin

This needs reopened as it should be a core part of Jenkins.

The multi-scm plugin does NOT work well with CI / GitHub integration.

[timja]

greenscar:

rodrigc: For GitHub, this would require you have an internal Web Service Git Hook server, as neither github.com nor self hosted enterprise has support for server side hooks.

An example:

1. I use the Workflow plugin to wrap 3 jobs: Checkout 1, Checkout 2, Build
2. I have a GitHook server which is called by a GitHub Hook on push or merge request.
3. This web service then calls the Jenkins job mentioned above.

Small companies cannot afford to maintain a GitHub Hook webserver and depend upon Jenkins capabilities.

Specific limitations of Jenkins even when using this "proof-of-concept" multi-scm plugin:

1. Jenkins has job / env vars for only 1 GIT repo.
2. The HTML display just says "Git Build Data" and "No Tags" for each repo. I must iterate through each of these links to find the repo I'm interested in.
3. The order of the repos in the list is critical to which env var Jenkins picks up.

If the Jenkins team is proposing their team does not work with GitHub / CI, this solution is good to go. Otherwise, the team needs to rethink the solution.

[timja]

jglick:

Jenkins Pipeline addresses this as a core feature, so I think this can be closed—we do not plan to implement it in freestyle projects.

[timja]

wilson_ds_net:

The Jenkins Pipeline is way over complicated for this simple need. I'm really surprised this hasn't come up before. If you aren't going to provide this feature, you could at lease direct users to an example of how to set up the complicated pipeline process so they have a clue as to what to do. Please re-evaluate your priorities and look at implementing a check box, rather than radio button idea for setting up access to multiple SCM repositories.

[timja]

oleg_nenashev:

"We" in the message below meant "jglick", no more. We have no such roadmap decisions.

If somebody wants to implement the feature, such contribution will be really appreciated. It could be done via SCM API extension and integration, but it's definitely not a trivial task

[timja]

greenscar:

We actually migrated our primary product to Jenkins Pipeline (for a Fortune 500 company) and this has resolved our issue. Pipeline still has its limitations but is worth the migration.

[timja]

[Originally duplicated by: JENKINS-9720]

[timja]

[Originally duplicated by: JENKINS-5158]