Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
There is an issue when building pull requests and the clone trait is present with shallow clone option.
Apparently you need some history in order to be able to do a merge.
We need to disable shallow clone when we know a merge will take place.
At the first look, this can be fixed in
com.cloudbees.jenkins.plugins.bitbucket.BitbucketGitSCMBuilder
org.jenkinsci.plugins.github_branch_source.GitHubSCMBuilder
I had identified the problem using bitbucket-branch-source-plugin but the should be visible on github-branch-source-plugin also..
Attachments
Issue Links
- blocks
-
-
- Open
-
- links to
Activity
Code changed in jenkins
User: Stephen Connolly
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMBuilder.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/main/java/org/jenkinsci/plugins/github_branch_source/MergeWithGitSCMExtension.java
src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMBuilderTest.java
http://jenkins-ci.org/commit/github-branch-source-plugin/3256676fa6a47d342a0442c59555df9eecde0b68
Log:
JENKINS-45771 Pick up consolidated MergeWithGitSCMExtension from git plugin
Required plugin updates:
- git-client 2.5.0
- git 3.5.0
- At least one of the optional plugin updates
Optional plugin updates: (update any of these if already have installed, do not need to install a plugin if not installed already)
- github-branch-source 2.2.3
- gitea 1.0.1
- bitbucket-branch-source 2.2.3
I found a case where this bug still applies in parallel stages, reopen this one since I think it is the same issue but please let me know if it is not and I can open another one
environment:
jenkins 2.89.3
github-branch-source-plugin 2.32.2
I have a multibranch project setup with
`discover the pull requests from origin`
`merge pull request with target`
fetch all tags
shallow clone
I also have Basic Branch Build Strategies Plugin installed to stop the build storm when we scan repo but I don't think it is related
my pipeline file has 2 parallel stages and one of the stages has its own node {} section to specify the builder label and workspace path.
it looks like this (this is almost the same example of https://jenkins.io/blog/2017/09/25/declarative-1, only difference here is that I have customWorkspace specified on the nodes to reuse the local code repo in the hope to save some time on git clone, our git repo is huge):
pipeline {
agent none
stages {
stage('Run Tests') {
parallel {
stage('Test 1') {
agent {
label "windows"
customWorkspace "${env.HOME}/TEST1"
}
steps {
bat "run-tests.bat"
}
post {
always {
junit "**/TEST-*.xml"
}
}
}
stage('Test On Linux') {
agent {
label "linux"
customWorkspace "${env.HOME}/TEST2"
}
steps {
sh "run-tests.sh"
}
post {
always {
junit "**/TEST-*.xml"
}
}
}
}
}
}
}
the error I am seeing is that when the pipeline enters the parallel stages, especially after the workspace switch, it will fail to merge if the PR is couple of commits behind master because the head of master is checked out without git history. ( I logged in to the builder after the failure and manually verified that in the workspace)
it seems that removing two ways to resolve this for now:
1 remove the the customWorkspace this is not going to work well for us because the lack of self clean on the branches of multibranch (without customworkspace different branch runs will not share workspace in current design of multibranch pipeline)
2. add 'wipe out workspace and clone again in advanced' settings. (this will increase our build time tremendously because our github repo is big, and unnecessary)
> /usr/local/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> /usr/local/bin/git config remote.origin.url !INFO_EXTRACTED! # timeout=10
Fetching upstream changes from !INFO_EXTRACTED!
> /usr/local/bin/git --version # timeout=10
using GIT_ASKPASS to set credentials JENKINS_GH
> /usr/local/bin/git fetch --tags --progress !INFO_EXTRACTED! +refs/pull/!INFO_EXTRACTED!/head:refs/remotes/origin/PR-!INFO_EXTRACTED! +refs/heads/master:refs/remotes/origin/master # timeout=60
Merging remotes/origin/master commit !INFO_EXTRACTED! into PR head commit !INFO_EXTRACTED!
> /usr/local/bin/git config core.sparsecheckout # timeout=10
> /usr/local/bin/git checkout -f !INFO_EXTRACTED!
> /usr/local/bin/git merge !INFO_EXTRACTED! # timeout=10
> /usr/local/bin/git config core.sparsecheckout # timeout=10
> /usr/local/bin/git checkout -f !INFO_EXTRACTED!
Command "/usr/local/bin/git merge !INFO_EXTRACTED!" returned status code 128:
stdout:
stderr: fatal: refusing to merge unrelated histories
FYI I remove the sensitive date from the output and replaced with ('!INFO_EXTRACTED')
Shiqi Yang
added a comment - - edited I found a case where this bug still applies in parallel stages, reopen this one since I think it is the same issue but please let me know if it is not and I can open another one
environment:
jenkins 2.89.3
github-branch-source-plugin 2.32.2
I have a multibranch project setup with
`discover the pull requests from origin`
`merge pull request with target`
fetch all tags
shallow clone
I also have Basic Branch Build Strategies Plugin installed to stop the build storm when we scan repo but I don't think it is related
my pipeline file has 2 parallel stages and one of the stages has its own node {} section to specify the builder label and workspace path.
it looks like this (this is almost the same example of https://jenkins.io/blog/2017/09/25/declarative-1 , only difference here is that I have customWorkspace specified on the nodes to reuse the local code repo in the hope to save some time on git clone, our git repo is huge):
pipeline {
agent none
stages {
stage( 'Run Tests' ) {
parallel {
stage( 'Test 1' ) {
agent {
label "windows"
customWorkspace "${env.HOME}/TEST1"
}
steps {
bat "run-tests.bat"
}
post {
always {
junit "**/TEST-*.xml"
}
}
}
stage( 'Test On Linux' ) {
agent {
label "linux"
customWorkspace "${env.HOME}/TEST2"
}
steps {
sh "run-tests.sh"
}
post {
always {
junit "**/TEST-*.xml"
}
}
}
}
}
}
}
the error I am seeing is that when the pipeline enters the parallel stages, especially after the workspace switch, it will fail to merge if the PR is couple of commits behind master because the head of master is checked out without git history. ( I logged in to the builder after the failure and manually verified that in the workspace)
it seems that removing two ways to resolve this for now:
1 remove the the customWorkspace this is not going to work well for us because the lack of self clean on the branches of multibranch (without customworkspace different branch runs will not share workspace in current design of multibranch pipeline)
2. add 'wipe out workspace and clone again in advanced' settings. (this will increase our build time tremendously because our github repo is big, and unnecessary)
> /usr/local/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> /usr/local/bin/git config remote.origin.url !INFO_EXTRACTED! # timeout=10
Fetching upstream changes from !INFO_EXTRACTED!
> /usr/local/bin/git --version # timeout=10
using GIT_ASKPASS to set credentials JENKINS_GH
> /usr/local/bin/git fetch --tags --progress !INFO_EXTRACTED! +refs/pull/!INFO_EXTRACTED!/head:refs/remotes/origin/PR-!INFO_EXTRACTED! +refs/heads/master:refs/remotes/origin/master # timeout=60
Merging remotes/origin/master commit !INFO_EXTRACTED! into PR head commit !INFO_EXTRACTED!
> /usr/local/bin/git config core.sparsecheckout # timeout=10
> /usr/local/bin/git checkout -f !INFO_EXTRACTED!
> /usr/local/bin/git merge !INFO_EXTRACTED! # timeout=10
> /usr/local/bin/git config core.sparsecheckout # timeout=10
> /usr/local/bin/git checkout -f !INFO_EXTRACTED!
Command "/usr/local/bin/git merge !INFO_EXTRACTED!" returned status code 128:
stdout:
stderr: fatal: refusing to merge unrelated histories
FYI I remove the sensitive date from the output and replaced with ('!INFO_EXTRACTED') Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA
Code changed in jenkins
User: Stephen Connolly
Path:
pom.xml
src/main/java/org/jenkinsci/plugin/gitea/GiteaSCMBuilder.java
src/main/java/org/jenkinsci/plugin/gitea/MergeWithGitSCMExtension.java
http://jenkins-ci.org/commit/gitea-plugin/ed08e75e55f227e7d001dfd84a234fd477c7b831
Log:
JENKINS-45771 Pick up consolidated MergeWithGitSCMExtension from git plugin