What are the reasons for using "Merging the pull request with the current target branch revision"

[Vitaly Karasik]

GitHub Branch Source Plugin uses "Merging the pull request with the current target branch revision" strategy by default for "Discover pull request". 

What are the reasons for using it  and not "The current pull request revision"?

TIA,

Vitaly

[James Nord]

the main reason for using it is you want to check that the result of a PR if merged would result in working code.

a PR can be based on any code even 1 year old, so this strategy makes sure it is up to date before building and testing.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3211ba6a-cc5f-44a2-acd8-d0fd31e4716c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steven Foster]

It would definitely be my preferred way of building code, but unfortunately the Jenkins master has to clone and perform the merge per pipeline every time. That doesn't scale on a sizeable repo with many active PRs and 12 multibranch pipelines :(

I've seen people merge PRs with an old base before and break things because they assumed that when their "Current pull request revision" build passes everything is fine.

[Vitaly Karasik]

James, Nord - thank you!

For my pipeline scaling is not an issue, but merging strategy is breaking SonarSource orchestration.

I think "The current pull request revision" will be nice  as far as I'll add a check that branch was updated from the master into pipeline itself.

[Viacheslav Dubrovskyi]

14.02.2019 12:58, Steven Foster пишет:

> It would definitely be my preferred way of building code, but
> unfortunately the Jenkins master has to clone and perform the merge
> per pipeline every time. That doesn't scale on a sizeable repo with
> many active PRs and 12 multibranch pipelines :(

Agree. And you must clone the repository at least 2 times. The first
time to get Jenkinsfile, the second for tests. It is very annoying. It
would be convenient to somehow be able to use previously cloned code.


--

WBD,
Viacheslav Dubrovskyi

[Mark Waite]

You may be able to reduce clone times by using a reference repository when performing the checkout from your pipeline.  I've found that an explicitly declared checkout significantly reduces the network data transfer and the disc usage when I have a reference repository on the agent and on the master.

https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-43931/Jenkinsfile shows an example in a scripted Pipeline.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/fd12342e-b2a3-e6b4-18a8-44a79aa22041%40gmail.com.

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

--

Thanks!

Mark Waite