Why did Multiple SCMs Plugin get deprecated?

[Martin Weber]

Hi,

on the wiki page it now reads:

> Users should migrate to Pipeline+Plugin.
> Pipeline offers a better way of checking out of multiple SCMs...

This is not true. Pipeline offers a *different* way of checking out multiple
SCMs. With the same branch seen in several SCMs, Pipeline only checks out the
branch from the *first SCM* only.

In contrast, Multiple SCMs Plugin checks out a branch from *each SCM* in
parallel. IMHO, a lot of people need this checkout behavior, have a look at
the installation stats [1].

If no one objects, I would request maintainership an un-deprecate it. I
already maintain the cmake plugin.


BTW: I'm always wondering what kind of use case is driving the Pipeline multi
SCM checkout behavior.


Martin


[1] https://plugins.jenkins.io/multiple-scms

--
E-Mails sollten Text sein, Text und nur Text.
Wenn Gott gewollt hätte, dass E-Mails in HTML geschrieben würden,
endeten Gebete traditionell mit </amen>.

[Mark Waite]

On Sat, Nov 10, 2018 at 10:12 AM Martin Weber <enten...@gmx.de> wrote:

Hi,

on the wiki page it now reads:

> Users should migrate to Pipeline+Plugin.
> Pipeline offers a better way of checking out of multiple SCMs...

This is not true. Pipeline offers a *different* way of checking out multiple
SCMs. With the same branch seen in several SCMs, Pipeline only checks out the
branch from the *first SCM* only.

I'm not a fan of the multiple SCM's plugin.  It has created complications in places that I didn't want to be complicated.  I use Pipeline to chekout independent branches from multiple SCM's and it works quite well.  I'm not sure why you say:

> Pipeline only checks out the branch from the *first SCM* only.

Could you explain further what you mean by that?

I've used Pipeline jobs to perform a checkout from an initial repository including a Jenkinsfile that defines the checkout of multiple other repositories into subdirectories in the workspace.  It works well.

I've never needed to put those checkout steps into parallel blocks, though I'm reasonably confident I can put them into parallel blocks for those cases where parallel would help.

 

In contrast, Multiple SCMs Plugin checks out a branch from *each SCM* in
parallel. IMHO, a lot of people need this checkout behavior, have a look at
the installation stats [1].

If no one objects, I would request maintainership an un-deprecate it. I
already maintain the cmake plugin.

I don't object, though I will continue to encourage users that want to checkout from multiple repositories to use Pipeline rather than using the Multiple SCMs plugin.

 

BTW: I'm always wondering what kind of use case is driving the Pipeline multi
SCM checkout behavior.


Martin


[1] https://plugins.jenkins.io/multiple-scms

--
E-Mails sollten Text sein, Text und nur Text.
Wenn Gott gewollt hätte, dass E-Mails in HTML geschrieben würden,
endeten Gebete traditionell mit </amen>.

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1556840.pInMiHzI7M%40linux.
For more options, visit https://groups.google.com/d/optout.

--

Thanks!

Mark Waite

[Daniel Beck]

> On 10. Nov 2018, at 18:12, Martin Weber <enten...@gmx.de> wrote:
>
> This is not true. Pipeline offers a *different* way of checking out multiple
> SCMs. With the same branch seen in several SCMs, Pipeline only checks out the
> branch from the *first SCM* only.
>
> In contrast, Multiple SCMs Plugin checks out a branch from *each SCM* in
> parallel.

What about resolveScm?

https://jenkins.io/doc/pipeline/steps/workflow-multibranch/#resolvescm-resolves-an-scm-from-an-scm-source-and-a-list-of-candidate-target-branch-names

[Martin Weber]

Ah, I wasn't aware of that.
Is there a way to suppress the 'fall back to master branch' behavior and make
it fail if the branch does not exist in the secondary SCM?
And would it trigger job run if polling detects a new commit in the secondary
SCM only?

/Martin

[Jesse Glick]

On Sat, Nov 10, 2018 at 12:12 PM Martin Weber <enten...@gmx.de> wrote:
> Pipeline offers a *different* way of checking out multiple
> SCMs. With the same branch seen in several SCMs, Pipeline only checks out the
> branch from the *first SCM* only.
>
> In contrast, Multiple SCMs Plugin checks out a branch from *each SCM* in
> parallel.

Daniel’s response, as well as the phrasing of the initial question,
are mixing up two very different things: multibranch projects and
plain projects. `multiple-scms` addresses a limitation in plain
(freestyle) projects that you could not have multiple SCM checkouts in
your workspace. This is trivially addressed in (plain) Pipeline
projects simply by doing something like

dir('first-repo') {
git 'http://git/first-repo'
}
dir('second-repo') {
git 'http://git/second-repo'
}

In other words, you may run the `checkout` step (or sugar like the
`git` step) one time, zero times, a hundred times, with whatever
arguments you want, in whatever locations you want; there is no need
for a special plugin to work around a limited model.

Your question implied that you were thinking about branch sources in a
multibranch project folder configuration, something quite unrelated to
multiple checkouts in a single build. In the rare case that more than
one is specified, a given branch project is loaded from just one
source—the first to claim its name. `checkout scm` uses that source.

The `resolveScm` step is for use from multibranch Pipelines with
multiple checkouts, and does not correspond to anything in freestyle
projects. I cannot answer any detailed questions about its behavior as
I am not its author, though from its description¹ it sounds like it
already supports the mode you describe, given suitable arguments. The
PR which added it² had no review. I think the feature would have
better placed in a separate plugin where it could be put up for
adoption, as it manages an advanced use case and I doubt the
maintainers of core Pipeline functionality have the time to deal with
it.

I hope this clears up the use case for which the `multiple-scms`
plugin was created, and why its use is discouraged as of the advent of
Pipeline.


¹ Pending formatting fixes to the static site, a live rendering such
as https://ci.jenkins.io/pipeline-syntax/html may be more usable.
² https://github.com/jenkinsci/workflow-multibranch-plugin/pull/46

[Martin Weber]

Am Dienstag, 13. November 2018, 20:40:41 CET schrieb Jesse Glick:
> On Sat, Nov 10, 2018 at 12:12 PM Martin Weber <enten...@gmx.de> wrote:
> > Pipeline offers a *different* way of checking out multiple
> > SCMs. With the same branch seen in several SCMs, Pipeline only checks out
> > the branch from the *first SCM* only.
> >
> > In contrast, Multiple SCMs Plugin checks out a branch from *each SCM* in
> > parallel.
>
> Daniel’s response, as well as the phrasing of the initial question,
> are mixing up two very different things: multibranch projects and
> plain projects. `multiple-scms` addresses a limitation in plain
> (freestyle) projects that you could not have multiple SCM checkouts in
> your workspace. This is trivially addressed in (plain) Pipeline
> projects simply by doing something like
>
> dir('first-repo') {
> git 'http://git/first-repo'
> }
> dir('second-repo') {
> git 'http://git/second-repo'
> }

Thanks, finally I got it working!
Just for the records; here is what I did (The documentation of resolveScm is
not very helpful and the snippet generator does not help much here)

checkout scm
dir('client_automation/src/shared') {
checkout resolveScm( source: [$class: 'GitSCMSource',
credentialsId: 'JenkinsGitCheckout',
excludes: '',
traits: [
[$class: 'jenkins.plugins.git.traits.CloneOptionTrait', depth:
0, noTags: true, reference: '', shallow: true],
[$class: 'jenkins.plugins.git.traits.BranchDiscoveryTrait']],
gitTool: 'InSearchPath', id: '_',
// ignoreOnPushNotifications: false,
includes: '',
remote:
'ssh://g...@example.com/develop/tessy-ite--automation-shared.git'
],
targets: [BRANCH_NAME]
)
}

But one question remains: Is it possible with resolveScm to poll multiple
repositories for changes and trigger a job?

> In other words, you may run the `checkout` step (or sugar like the
> `git` step) one time, zero times, a hundred times, with whatever

A plain `git` step does not work, it lacks the BranchDiscoveryTrait.

Martin

[Mark Waite]

On Wed, Mar 27, 2019 at 2:02 PM Martin Weber <enten...@gmx.de> wrote:

Am Dienstag, 13. November 2018, 20:40:41 CET schrieb Jesse Glick:
> On Sat, Nov 10, 2018 at 12:12 PM Martin Weber <enten...@gmx.de> wrote:
> > Pipeline offers a *different* way of checking out multiple
> > SCMs. With the same branch seen in several SCMs, Pipeline only checks out
> > the branch from the *first SCM* only.
> >
> > In contrast, Multiple SCMs Plugin checks out a branch from *each SCM* in
> > parallel.
>
> Daniel’s response, as well as the phrasing of the initial question,
> are mixing up two very different things: multibranch projects and
> plain projects. `multiple-scms` addresses a limitation in plain
> (freestyle) projects that you could not have multiple SCM checkouts in
> your workspace. This is trivially addressed in (plain) Pipeline
> projects simply by doing something like
>
> dir('first-repo') {
>   git 'http://git/first-repo'
> }
> dir('second-repo') {
>   git 'http://git/second-repo'
> }

Thanks, finally I got it working!
Just for the records; here is what I did (The documentation of resolveScm is
not very helpful and the snippet generator does not help much here)

I think you may find it easier to use checkout without using resolveScm.  Can you help me understand why you chose to use resolveScm?

See the following examples for multiple checkouts in a single Jenkinsfile.

https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-43198/Jenkinsfile 

https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-47874/Jenkinsfile

Mark Waite 

 

--
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-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4238774.buQomSH1gE%40linux.

For more options, visit https://groups.google.com/d/optout.

--

Thanks!

Mark Waite

[Martin Weber]

D. Beck suggested that earlier in this thread.

>
> See the following examples for multiple checkouts in a single Jenkinsfile.
>
> https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-43198/Jenkinsfile
> https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-47874/Jenkinsfile

Hmmh, do these examples really monitor different SCMs for changes and trigger
a build?

Anyway, thanks for your response.

[Stephen Connolly]

ResolveSCM is for the use case where you want to checkout a matching branch name in another repo... but fallback to other branches of it doesn’t exist.

Eg Apache Maven uses it so that you can add a feature to Core (main git repo) and add integration tests (side git repo) and test them both in the same build.

HTH 

--
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-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/32380527.vBj4gx0osB%40linux.

For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone