Jenkins Git Refspec not correctly substituted for branch specifier

Question

I am busy integrating Jenkins and TFS. My first unsuccesful attempt was to use Jenkins's multibranch pipeline setup and TFS. So my second attempt is to use a single Jenkins build with a parameter to specify which branch to build.

I've called this parameter branchRef and am using it in the "branches to build" field like ${branchRef}

According to Team Foundation Server plugin for Jenkins I would have to specify the Refspec as follows: +refs/heads/*:refs/remotes/origin/* +refs/pull/*:refs/remotes/origin-pull/* This will give me a list of refs like:

44553f3184c5cbe04e9838209bc752218cd7e54a refs/remotes/origin-pull/563/merge
8bf10538ee29e9df0745ed4b7b23cb20fe56978d refs/remotes/origin/feature/integration
fa8c14671cb6ce1c3ef6dcca52e9e1f45e914e00 refs/remotes/origin/feature/stable

Within TFS I've setup the Build Definition to use a Job parameter like: branchRef=$(Build.SourceBranch). When building a branch and pull-request (merge) I get the following as a parameter:

normal branch: refs/heads/integration
pull-request merge: refs/pull/563/merge

This gives the following Jenkins behaviour

->normal branch
 > git.exe rev-parse "refs/remotes/origin/integration^{commit}" # timeout=10
->pull-request
 > git.exe rev-parse "refs/pull/563/merge^{commit}" # timeout=10

So the normal branch Jenkins/Git plugin is translating from refs/heads/integration to refs/remotes/origin/integration while the pull-request it does not 'translate'.

I've implemented a workaround, which was to change the Refspec to: +refs/pull/*:refs/pull/* +refs/heads/*:refs/remotes/origin/* but I don't know if this will or will not cause issues in the long run.

Have you encountered any issues with your workaround for now? Just monitor it, If no issues that should be a good workaround. — Andy Li-MSFT

tehp tehp · Accepted Answer · 2018-06-07T00:07:36

I tested this by trying to duplicate your setup and noticed the same thing:

So the normal branch Jenkins/Git plugin is translating from refs/heads/integration to refs/remotes/origin/integration while the pull-request it does not 'translate'.

This should not cause any issues in it's current state (unless this confusing behaviour is changed), since the remotes should be fetched each time. As far as I can tell, refs/heads/integration becoming refs/remotes/origin/integration is irrelevant if you haven't made any local changes on heads and remotes/origin is fetched.

If you want to be absolutely sure you can compare them using: git rev-list --count refs/heads/integration..refs/remotes/origin/integration (it should be 0 if they are the same).

The difference between heads and remotes/origin might be relevant here.

Jenkins Git Refspec not correctly substituted for branch specifier

1 Answers