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
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.
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.
On Thursday, February
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
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.
On Thu, 14 Feb 2019, 05:58 Vitaly Karasik GitHub Branch
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
--
You received this message because you are
