[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title Shiqi Yang closed an issue as Not A Defect Jenkins / JENKINS-50755 multibranch pipeline creates outdated refs when set to run Pull Requests Change By: Shiqi Yang Status: Open Closed Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title Shiqi Yang commented on JENKINS-50755 Re: multibranch pipeline creates outdated refs when set to run Pull Requests further investigation shows that this is a git/github issue...closing Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title
Shiqi Yang updated an issue
Jenkins / JENKINS-50755
multibranch pipeline creates outdated refs when set to run Pull Requests
Change By:
Shiqi Yang
we have a multibranch pipeline job set to build on github Pull Requests with per-merge (Discover pull requests from origin) and (Merging the pull request with the current target branch revision)we have advanced clone behaviors 'Fetch tags' checked'clean after checkout' 'Prune stale remote-tracking branches' and 'wipe out repository & force clone' are all enabledin the job we are also running some reporting and we want to know the head of pull request (before jenkins merge target branch to it) and the way we are doing that is to run a script that runs {code:none}git show -s {BRANCH_NAME}{code}to get the original commit sha. I found that during the run jenkins will create a local ref named `remote/origin/PR-XXX` and jenkins will use that as the rev for running the job. and I believe that is done by command like this:{code:none} ` git fetch --tags --progress GIT_REPO_URL +refs/pull/XXX/head:refs/remotes/origin/PR-XXX +refs/heads/master:refs/remotes/origin/master --prune ` {code} and in this case the $BRANCH_NAME set by jenkins multibranch pipeline will be `PR-XXX` it createsso this worked for me at the beginningbut the problem I am having is that sometimes my git show command doesn't return the head of the pull request but rather an old commit of the same pull request, and I was able to login to one of our builders and investigate, it turns out that `git fetch` command above did not actually create the ref `remotes/origin/PR-XXX` correctly. what's puzzled me even more is that jenkins plugin was able to show the latest commit in its loge.g. the merge right after the git fetch command will show the correct commit shaMerging remotes/origin/master commit into PR head commit the is the right sha that I want. so on the builder you see the following state:at the workspace directory `git show` will show you all the commits correctly (after merge)`git show origin/PR-XXX` will show the old outdated pull request headI ruled out couple of things by poking around:1. the workspace gets completely wiped out before each run, so it won't be that the ref was there from previous runs, and even if was, the fetch command within the current run should have it updated to latest, besides, some of those runs happened on new builders that never run that PR before.2. this should not be github server update delay because sometimes we can repro this again in rerun of the job which happens hours after the head of the PR was updated.and I wasn't able to get a constant repro case on this, only thing I know is that if my PR run fell into that state, I'd have to push another dummy change to fix it, and sometimes I have to push more changes...
[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title
Shiqi Yang updated an issue
Jenkins / JENKINS-50755
multibranch pipeline creates outdated refs when set to run Pull Requests
Change By:
Shiqi Yang
we have a multibranch pipeline job set to build on github Pull Requests with per-merge (Discover pull requests from origin) and (Merging the pull request with the current target branch revision)we have advanced clone behaviors 'Fetch tags' checked'clean after checkout' 'Prune stale remote-tracking branches' and 'wipe out repository & force clone' are all enabledin the job we are also running some reporting and we want to know the head of pull request (before jenkins merge target branch to it) and the way we are doing that is to run a script that runs {code: shell none }git show -s {BRANCH_NAME}{code}to get the original commit sha. I found that during the run jenkins will create a local ref named `remote/origin/PR-XXX` and jenkins will use that as the rev for running the job. and I believe that is done by command like this: {code:none} `git fetch --tags --progress GIT_REPO_URL +refs/pull/XXX/head:refs/remotes/origin/PR-XXX +refs/heads/master:refs/remotes/origin/master --prune` {code} and in this case the $BRANCH_NAME set by jenkins multibranch pipeline will be `PR-XXX` it createsso this worked for me at the beginningbut the problem I am having is that sometimes my git show command doesn't return the head of the pull request but rather an old commit of the same pull request, and I was able to login to one of our builders and investigate, it turns out that `git fetch` command above did not actually create the ref `remotes/origin/PR-XXX` correctly. what's puzzled me even more is that jenkins plugin was able to show the latest commit in its loge.g. the merge right after the git fetch command will show the correct commit shaMerging remotes/origin/master commit into PR head commit the is the right sha that I want. so on the builder you see the following state:at the workspace directory `git show` will show you all the commits correctly (after merge)`git show origin/PR-XXX` will show the old outdated pull request headI ruled out couple of things by poking around:1. the workspace gets completely wiped out before each run, so it won't be that the ref was there from previous runs, and even if was, the fetch command within the current run should have it updated to latest, besides, some of those runs happened on new builders that never run that PR before.2. this should not be github server update delay because sometimes we can repro this again in rerun of the job which happens hours after the head of the PR was updated.and I wasn't able to get a constant repro case on this, only thing I know is that if my PR run fell into that state, I'd have to push another dummy change to fix it, and sometimes I have to push more changes...
[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title
Shiqi Yang updated an issue
Jenkins / JENKINS-50755
multibranch pipeline creates outdated refs when set to run Pull Requests
Change By:
Shiqi Yang
we have a multibranch pipeline job set to build on github Pull Requests with per-merge (Discover pull requests from origin) and (Merging the pull request with the current target branch revision)we have advanced clone behaviors 'Fetch tags' checked'clean after checkout' 'Prune stale remote-tracking branches' and 'wipe out repository & force clone' are all enabledin the job we are also running some reporting and we want to know the head of pull request (before jenkins merge target branch to it) and the way we are doing that is to run a script that runs { { code:shell} git show -s {BRANCH_NAME} {code } } to get the original commit sha. I found that during the run jenkins will create a local ref named `remote/origin/PR-XXX` and jenkins will use that as the rev for running the job. and I believe that is done by command like this:`git fetch --tags --progress GIT_REPO_URL +refs/pull/XXX/head:refs/remotes/origin/PR-XXX +refs/heads/master:refs/remotes/origin/master --prune` and in this case the $BRANCH_NAME set by jenkins multibranch pipeline will be `PR-XXX` it createsso this worked for me at the beginningbut the problem I am having is that sometimes my git show command doesn't return the head of the pull request but rather an old commit of the same pull request, and I was able to login to one of our builders and investigate, it turns out that `git fetch` command above did not actually create the ref `remotes/origin/PR-XXX` correctly. what's puzzled me even more is that jenkins plugin was able to show the latest commit in its loge.g. the merge right after the git fetch command will show the correct commit shaMerging remotes/origin/master commit into PR head commit the is the right sha that I want. so on the builder you see the following state:at the workspace directory `git show` will show you all the commits correctly (after merge)`git show origin/PR-XXX` will show the old outdated pull request headI ruled out couple of things by poking around:1. the workspace gets completely wiped out before each run, so it won't be that the ref was there from previous runs, and even if was, the fetch command within the current run should have it updated to latest, besides, some of those runs happened on new builders that never run that PR before.2. this should not be github server update delay because sometimes we can repro this again in rerun of the job which happens hours after the head of the PR was updated.and I wasn't able to get a constant repro case on this, only thing I know is that if my PR run fell into that state, I'd have to push another dummy change to fix it, and sometimes I have to push more changes...
[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title
Shiqi Yang updated an issue
Jenkins / JENKINS-50755
multibranch pipeline creates outdated refs when set to run Pull Requests
Change By:
Shiqi Yang
we have a multibranch pipeline job set to build on github Pull Requests with per-merge (Discover pull requests from origin) and (Merging the pull request with the current target branch revision)we have advanced clone behaviors 'Fetch tags' checked'clean after checkout' 'Prune stale remote-tracking branches' and 'wipe out repository & force clone' are all enabledin the job we are also running some reporting and we want to know the head of pull request (before jenkins merge target branch to it) and the way we are doing that is to run a script that runs {{git show -s {BRANCH_NAME}}} to get the original commit sha. I found that during the run jenkins will create a local ref named `remote/origin/PR-XXX` and jenkins will use that as the rev for running the job. and I believe that is done by command like this:`git fetch --tags --progress GIT_REPO_URL +refs/pull/XXX/head:refs/remotes/origin/PR-XXX +refs/heads/master:refs/remotes/origin/master --prune` and in this case the $BRANCH_NAME set by jenkins multibranch pipeline will be `PR-XXX` it createsso this worked for me at the beginningbut the problem I am having is that sometimes my git show command doesn't return the head of the pull request but rather an old commit of the same pull request, and I was able to login to one of our builders and investigate, it turns out that `git fetch` command above did not actually create the ref `remotes/origin/PR-XXX` correctly. what's puzzled me even more is that jenkins plugin was able to show the latest commit in its loge.g. the merge right after the git fetch command will show the correct commit shaMerging remotes/origin/master commit into PR head commit the is the right sha that I want. so on the builder you see the following state:at the workspace directory `git show` will show you all the commits correctly (after merge)`git show origin/PR-XXX` will show the old outdated pull request headI ruled out couple of things by poking around:1. the workspace gets completely wiped out before each run, so it won't be that the ref was there from previous runs, and even if was, the fetch command within the current run should have it updated to latest, besides, some of those runs happened on new builders that never run that PR before.2. this should not be github server update delay because sometimes we can repro this again in rerun of the job which happens hours after the head of the PR was updated.and I wasn't able to get a constant repro case on this, only thing I know is that if my PR run fell into that state, I'd have to push another dummy change to fix it, and sometimes I have to push more changes...
[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title
Shiqi Yang updated an issue
Jenkins / JENKINS-50755
multibranch pipeline creates outdated refs when set to run Pull Requests
Change By:
Shiqi Yang
we have a multibranch pipeline job set to build on github Pull Requests with per-merge (Discover pull requests from origin) and (Merging the pull request with the current target branch revision)we have advanced clone behaviors 'Fetch tags' checked'clean after checkout' 'Prune stale remote-tracking branches' and 'wipe out repository & force clone' are all enabledin the job we are also running some reporting and we want to know the head of pull request (before jenkins merge target branch to it) and the way we are doing that is to run a script that runs ` {{ git show -s {BRANCH_NAME} ` }} to get the original commit sha. I found that during the run jenkins will create a local ref named `remote/origin/PR-XXX` and jenkins will use that as the rev for running the job. and I believe that is done by command like this:`git fetch --tags --progress GIT_REPO_URL +refs/pull/XXX/head:refs/remotes/origin/PR-XXX +refs/heads/master:refs/remotes/origin/master --prune` and in this case the $BRANCH_NAME set by jenkins multibranch pipeline will be `PR-XXX` it createsso this worked for me at the beginningbut the problem I am having is that sometimes my git show command doesn't return the head of the pull request but rather an old commit of the same pull request, and I was able to login to one of our builders and investigate, it turns out that `git fetch` command above did not actually create the ref `remotes/origin/PR-XXX` correctly. what's puzzled me even more is that jenkins plugin was able to show the latest commit in its loge.g. the merge right after the git fetch command will show the correct commit shaMerging remotes/origin/master commit into PR head commit the is the right sha that I want. so on the builder you see the following state:at the workspace directory `git show` will show you all the commits correctly (after merge)`git show origin/PR-XXX` will show the old outdated pull request headI ruled out couple of things by poking around:1. the workspace gets completely wiped out before each run, so it won't be that the ref was there from previous runs, and even if was, the fetch command within the current run should have it updated to latest, besides, some of those runs happened on new builders that never run that PR before.2. this should not be github server update delay because sometimes we can repro this again in rerun of the job which happens hours after the head of the PR was updated.and I wasn't able to get a constant repro case on this, only thing I know is that if my PR run fell into that state, I'd have to push another dummy change to fix it, and sometimes I have to push more changes...
[JIRA] (JENKINS-50755) multibranch pipeline creates outdated refs when set to run Pull Requests
Title: Message Title
Shiqi Yang created an issue
Jenkins / JENKINS-50755
multibranch pipeline creates outdated refs when set to run Pull Requests
Issue Type:
Bug
Assignee:
Unassigned
Components:
github-branch-source-plugin
Created:
2018-04-12 01:41
Environment:
jenkins 2.73.3 GitHub Branch Source 2.3.2 Git Plugin 3.7.0 Git Client Plugin 2.7.0
Priority:
Major
Reporter:
Shiqi Yang
we have a multibranch pipeline job set to build on github Pull Requests with per-merge (Discover pull requests from origin) and (Merging the pull request with the current target branch revision) we have advanced clone behaviors 'Fetch tags' checked 'clean after checkout' 'Prune stale remote-tracking branches' and 'wipe out repository & force clone' are all enabled in the job we are also running some reporting and we want to know the head of pull request (before jenkins merge target branch to it) and the way we are doing that is to run a script that runs `git show -s {BRANCH_NAME} ` to get the original commit sha. I found that during the run jenkins will create a local ref named `remote/origin/PR-XXX` and jenkins will use that as the rev for running the job. and I believe that is done by command like this: `git fetch --tags --progress GIT_REPO_URL +refs/pull/XXX/head:refs/remotes/origin/PR-XXX +refs/heads/master:refs/remotes/origin/master --prune` and in this case the $BRANCH_NAME set by jenkins multibranch pipeline will be `PR-XXX` it creates so this worked for me at the beginning but the problem I am having is that sometimes my git show command doesn't return the head of the pull request but rather an old commit of the same pull request, and I was able to login to one of our builders and investigate, it turns out that `git fetch` command above did not actually create the ref
