Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Blocker
-
Resolution: Cannot Reproduce
-
Component/s: pretested-integration-plugin
-
Labels:None
-
Environment: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
-
Similar Issues:
Description
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.
Attachments
Activity
**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.
Al Ferguson
added a comment - - edited ** 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.
Bue Petersen
added a comment - 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?
Al Ferguson
added a comment - 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
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.