-
Bug
-
Resolution: Cannot Reproduce
-
Blocker
-
None
-
Jenkins 1.545
Jenkins GIT plugin 2.2.9
Pretested integration plugin 2.1.2
JDK 1.7.0_45
os Linux amd64 2.6.32-5
-
Powered by SuggestiMate
The plugin doesn't find the integration branch, it always throws an NothingToDoException (because 'found' is false).
Either "client.getRemoteBranches()" or "Branch.getName()" does not work.
We get same behavior using any strategy (squash & no-ff).
Jenkins GIT plugin is up-to-date, however the git installation on os is not.
[JENKINS-25831] Branch not found (our case 12373)
If you by "origin/int" means the repository remote named "origin", and branch "int" you have to use just "int" in the integration branch field. Your branch specifier can still include "origin".
The plugin in version 2.1.2 assumes you try to integrate to a repository called origin.
This implicit assumption will be changed in next version.
Note only one git repository is supported in current version.
Branch specifier: origin/dev
Integration branch: int
***Console Output*************************************************************************
15:18:37 > git rev-parse --is-inside-work-tree # timeout=10
15:18:37 Fetching changes from the remote Git repository
15:18:37 > git config remote.origin.url git@bitbucket.org:*******/**-backend.git # timeout=10
15:18:37 Pruning obsolete local branches
15:18:37 Fetching upstream changes from git@bitbucket.org:*******/**-backend.git
15:18:37 > git --version # timeout=10
15:18:37 > git fetch --tags --progress git@bitbucket.org:*******/*-backend.git +refs/heads/:refs/remotes/origin/* --prune
15:18:38 > git rev-parse refs/remotes/origin/dev^
15:18:38 > git rev-parse refs/remotes/origin/origin/dev^{commit}
# timeout=10
15:18:38 Checking out Revision 939a053e91a5a0b1057733393e66473896f30f6b (refs/remotes/origin/dev)
15:18:38 > git config core.sparsecheckout # timeout=10
15:18:38 > git checkout -f 939a053e91a5a0b1057733393e66473896f30f6b
15:18:38 > git rev-list 939a053e91a5a0b1057733393e66473896f30f6b # timeout=10
15:18:38 Cleaning workspace
15:18:38 > git rev-parse --verify HEAD # timeout=10
15:18:38 Resetting working tree
15:18:38 > git reset --hard # timeout=10
15:18:38 > git clean -fdx # timeout=10
15:18:38 2.1.2
15:18:38 Checking out integration target branch int and pulling latest changes
15:18:38 [workspace] $ git checkout int
15:18:38 [workspace] $ git pull origin int
15:18:38 Preparing to merge changes in commit 939a053e91a5a0b1057733393e66473896f30f6b to integration branch int(948a6ba75a921cd8a649a069bef0e857289d526e)
15:18:38 Nothing to do
15:18:39 Finished: NOT_BUILT
******************************************************************************
***Log Recorders*************************************************************************
Nov 28, 2014 3:18:38 PM FINER PretestedIntegrationAction getCurrentIntegrationTip
RETURN
Nov 28, 2014 3:18:38 PM FINER Commit getId
ENTRY
Nov 28, 2014 3:18:38 PM FINER Commit getId
RETURN
Nov 28, 2014 3:18:38 PM FINER GitBridge getBranch
RETURN
Nov 28, 2014 3:18:38 PM FINER GitBridge getBranch
ENTRY
Nov 28, 2014 3:18:38 PM SEVERE org.jenkinsci.plugins.pretestedintegration.PretestedIntegrationBuildWrapper setUp
[PREINT] - setUp()
org.jenkinsci.plugins.pretestedintegration.exceptions.NothingToDoException: Nothing to do
at org.jenkinsci.plugins.pretestedintegration.scm.git.SquashCommitStrategy.integrate(SquashCommitStrategy.java:84)
at org.jenkinsci.plugins.pretestedintegration.AbstractSCMBridge.mergeChanges(AbstractSCMBridge.java:105)
******************************************************************************
It still doesn't work. The version of the git installation on the server was 1.7.2.5. Upgraded to 1.7.10.4, no effect, same behavior.
I'm told there might be a dependency on git 1.8 or newer. Related to using squash commit and maybe adding new files in the commits.
No wait a moment, it seems like we are testing with git 1.7.9.5 on the build slaves.
I will ask a developer to briefly look at the problem, but else I will recommend to wait for the release that comes out in the following week.
Just a note...
What is the polling log for the build you have problems with?
I know there is problems with manual builds, and sometimes also related to using triggers from other systems.
**POLLING LOG*****************************
Started on Dec 1, 2014 3:28:02 PM
Using strategy: Default
[poll] Last Built Revision: Revision 939a053e91a5a0b1057733393e66473896f30f6b (refs/remotes/origin/dev)
> git ls-remote -h git@bitbucket.org:alogient/gcr-backend.git dev # timeout=10
[poll] Latest remote head revision is: 29371be20a7c9207271632e102bf4afef95e2340
Done. Took 0.43 sec
Changes found
*********************************************
I don't think this situation is the result of a polling problem.
The problem is that SquashCommitStrategy cannot find the remote branch ("The branch name (refs/remotes/origin/dev) contained in the git build data object, did not match a remote branch name").
The code for this class has not been changed since the last release, so I have my doubts that it will be fixed for the release you plan this week.
We have some internal changes that are not published yet as we are writing tests for them.
I talked to our developer, and I think we have found the problem.
Are you using refspecs for polling? We notice that " [poll] Last Built Revision: Revision 939a053e91a5a0b1057733393e66473896f30f6b (refs/remotes/origin/dev)" contain "refs/remotes/origin", where we would typically only expect "origin".
The new version will have a remote repository name to match against in the pretested plugin configuration, so this means you can put "refs/remotes/origin" in that field and it should work.
Right now the only work-around is change your git configuration, so it will look like this "[poll] Last Built Revision: Revision 939a053e91a5a0b1057733393e66473896f30f6b (origin/dev)".
I know the plugin is a bit shaky right now, but it was a proof-of-concept not long ago and we are still gathering issues around the corner-cases.
Your plugin is very interesting because it provides a solution to a situation we are facing.
No, we don't use refspecs, only the branch specifier.
The value in the branch specifier was 'origin/dev'. If I change this value to '**/dev' IT WORKS! Hooray!
Using a wildcard is not ideal, I don't understand the exact value to specify in your workaround. Can you specify the 'branch specifier' value you you suggested in your workaround?
Resolving this as irrelevant, since we haven't hear anything on this topic for almost 1 1/2 year
Branch specifier: origin/dev
Integration branch: origin/int