• Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Blocker 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

      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)

          Al Ferguson added a comment - - edited

          Branch specifier: origin/dev
          Integration branch: origin/int

          Al Ferguson added a comment - - edited Branch specifier: origin/dev Integration branch: origin/int

          Bue Petersen added a comment -

          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.

          Bue Petersen added a comment - 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.

          Al Ferguson added a comment - - edited

          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^

          {commit} # timeout=10
          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.

          Al Ferguson added a comment - - edited 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^ {commit} # timeout=10 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.

          Bue Petersen added a comment -

          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.

          Bue Petersen added a comment - 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.

          Bue Petersen added a comment -

          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.

          Bue Petersen added a comment - 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.

          Bue Petersen added a comment -

          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.

          Bue Petersen added a comment - 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.

          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.

          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.

          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.

          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.

          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?

          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?

          Lars Kruse added a comment -

          Resolving this as irrelevant, since we haven't hear anything on this topic for almost 1 1/2 year

          Lars Kruse added a comment - Resolving this as irrelevant, since we haven't hear anything on this topic for almost 1 1/2 year

            praqma Praqma Support
            alfernie Al Ferguson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: