Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20939

git plugin doesn't detect changes when I create duplicate sub name branch.

    Details

    • Similar Issues:

      Description

      After the branch creation, Git repository has following branches:
      % git branch -l -r
      origin/HEAD -> origin/master
      origin/develop/master
      origin/master
      You can see `master' and `develop/master' have duplicate sub name.
      I specified `master' branch to poll changes (and not specify develop/master).

      I notice that following command outputs two lines. This behavior might be a hint.
      % git ls-remote repo.git master
      f51fe2b0cb10c3187bad89af860a3a365623db35 refs/heads/develop/master
      7216584eec594056800ba76840b0508b0d7453a2 refs/heads/master

        Attachments

          Issue Links

            Activity

            Hide
            dazwin Darren Warner added a comment -

            I have the same issue (I'm using Git Publisher to update a branch when a build is successful).

            The problem appears to be here (git-client-plugin/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java):

                public ObjectId getHeadRev(String url, String branch) throws GitException, InterruptedException {
            	String[] branchExploded = branch.split("/");
            	branch = branchExploded[branchExploded.length-1];
                    ....
                    args.add(branch);
            

            Only the last path element of branch is provided to the command line, resulting in the behavior the reporter mentions above.

            Why not just pass 'branch' to the command line verbatim (-h is already added, so there's no danger of pulling a tag)?

            Show
            dazwin Darren Warner added a comment - I have the same issue (I'm using Git Publisher to update a branch when a build is successful). The problem appears to be here (git-client-plugin/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java): public ObjectId getHeadRev( String url, String branch) throws GitException, InterruptedException { String [] branchExploded = branch.split( "/" ); branch = branchExploded[branchExploded.length-1]; .... args.add(branch); Only the last path element of branch is provided to the command line, resulting in the behavior the reporter mentions above. Why not just pass 'branch' to the command line verbatim (-h is already added, so there's no danger of pulling a tag)?
            Hide
            dazwin Darren Warner added a comment - - edited

            Commit ded4597c seems to be the culprit. It's a big commit and I'm no where near familiar enough with git-client-plugin or IGitAPI to understand why this was done.

            Show
            dazwin Darren Warner added a comment - - edited Commit ded4597c seems to be the culprit. It's a big commit and I'm no where near familiar enough with git-client-plugin or IGitAPI to understand why this was done.
            Hide
            markewaite Mark Waite added a comment - - edited

            The git-client-plugin 1.6.4 and git-plugin 2.0.4 include an improvement for better handling of namespace branches (like develop/master in this example). Could you check if the behavior is any better with those plugin versions than with previous plugin versions?

            Show
            markewaite Mark Waite added a comment - - edited The git-client-plugin 1.6.4 and git-plugin 2.0.4 include an improvement for better handling of namespace branches (like develop/master in this example). Could you check if the behavior is any better with those plugin versions than with previous plugin versions?
            Hide
            dazwin Darren Warner added a comment - - edited

            It just killed our authorization...

            hudson.util.IOException2: hudson.plugins.git.GitException: Failed to connect to http://####@#########/###.git using credentials (status = 401)
            at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:458)
            at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
            at hudson.scm.SCM.poll(SCM.java:373)
            at hudson.model.AbstractProject._poll(AbstractProject.java:1581)
            at hudson.model.AbstractProject.poll(AbstractProject.java:1490)
            at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:462)
            at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:491)
            at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
            at java.util.concurrent.FutureTask.run(FutureTask.java:166)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:679)

            Show
            dazwin Darren Warner added a comment - - edited It just killed our authorization... hudson.util.IOException2: hudson.plugins.git.GitException: Failed to connect to http://####@#########/###.git using credentials (status = 401) at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:458) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356) at hudson.scm.SCM.poll(SCM.java:373) at hudson.model.AbstractProject._poll(AbstractProject.java:1581) at hudson.model.AbstractProject.poll(AbstractProject.java:1490) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:462) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:491) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679)
            Hide
            markewaite Mark Waite added a comment -

            Sorry for that damage. I don't think the change related to namespaces and branches is what caused the authorization change. The transition from 1.6.3 to 1.6.4 also includes an upgrade from an obsolete Apache http Java library to a more current (but slightly different) Apache http library.

            • Is your URL really "http" rather than "https"?
            • Can you duplicate the same failure with a publicly visible URL (so that it a debugger can be attached to watch it fail)?
            • If you're using https, are you using a self-signed certificate?
            • Does reverting to git-client-plugin 1.6.3 work for you?
            • Are there any other hints you can offer which might suggest how your installation is different than the installations which are working with git-client-plugin 1.6.4?
            Show
            markewaite Mark Waite added a comment - Sorry for that damage. I don't think the change related to namespaces and branches is what caused the authorization change. The transition from 1.6.3 to 1.6.4 also includes an upgrade from an obsolete Apache http Java library to a more current (but slightly different) Apache http library. Is your URL really "http" rather than "https"? Can you duplicate the same failure with a publicly visible URL (so that it a debugger can be attached to watch it fail)? If you're using https, are you using a self-signed certificate? Does reverting to git-client-plugin 1.6.3 work for you? Are there any other hints you can offer which might suggest how your installation is different than the installations which are working with git-client-plugin 1.6.4?
            Hide
            dazwin Darren Warner added a comment -

            Is your URL really "http" rather than "https"?

            Yes

            Can you duplicate the same failure with a publicly visible URL (so that it a debugger can be attached to watch it fail)?

            Unfortunately, no - this is a commercial product.

            Does reverting to git-client-plugin 1.6.3 work for you?

            Yes. Git plugin at 2.0.4 is Ok.

            Are there any other hints you can offer which might suggest how your installation is different than the installations which are working with git-client-plugin 1.6.4?

            I'm using 'Credentials' - there probably aren't that many Auth + non-HTTPS set-ups out there.

            I'll try running a trace on the git conversation next to see if that yields anything interesting.

            Show
            dazwin Darren Warner added a comment - Is your URL really "http" rather than "https"? Yes Can you duplicate the same failure with a publicly visible URL (so that it a debugger can be attached to watch it fail)? Unfortunately, no - this is a commercial product. Does reverting to git-client-plugin 1.6.3 work for you? Yes. Git plugin at 2.0.4 is Ok. Are there any other hints you can offer which might suggest how your installation is different than the installations which are working with git-client-plugin 1.6.4? I'm using 'Credentials' - there probably aren't that many Auth + non-HTTPS set-ups out there. I'll try running a trace on the git conversation next to see if that yields anything interesting.
            Hide
            dazwin Darren Warner added a comment -

            It appears that 1.6.4 is not sending an Authorization header - this happens in the very first call to /info/refs. Apache is sending back a 401 Authorization Required and the build fails.

            In 1.6.3, Authorization is sent in the very first call. Interestingly, this isn't necessarily the case for future calls - it looks like a 401 + resend chat is the norm for subsequent requests (either because no auth is sent, or the auth is apparantly invalid).

            So either 1.6.4 needs to sent an Authorization header up-front, or it needs to gracefully handle a 401 response.

            Show
            dazwin Darren Warner added a comment - It appears that 1.6.4 is not sending an Authorization header - this happens in the very first call to /info/refs. Apache is sending back a 401 Authorization Required and the build fails. In 1.6.3, Authorization is sent in the very first call. Interestingly, this isn't necessarily the case for future calls - it looks like a 401 + resend chat is the norm for subsequent requests (either because no auth is sent, or the auth is apparantly invalid). So either 1.6.4 needs to sent an Authorization header up-front, or it needs to gracefully handle a 401 response.
            Hide
            markewaite Mark Waite added a comment -

            I can see a behavior change from 1.6.3 (ok) to 1.6.4 (fails to clone) when connecting to a private bitbucket repository using https. In the bitbucket case, I stored my bitbucket username and password in a Jenkins credential.

            I don't see a behavior change from 1.6.3 (ok) to 1.6.4 (ok) when connecting to a private github repository using https. In the github case, I generated an access token and used my user name and that access token from a Jenkins credential.

            Show
            markewaite Mark Waite added a comment - I can see a behavior change from 1.6.3 (ok) to 1.6.4 (fails to clone) when connecting to a private bitbucket repository using https. In the bitbucket case, I stored my bitbucket username and password in a Jenkins credential. I don't see a behavior change from 1.6.3 (ok) to 1.6.4 (ok) when connecting to a private github repository using https. In the github case, I generated an access token and used my user name and that access token from a Jenkins credential.
            Hide
            markewaite Mark Waite added a comment - - edited

            Refer to JENKINS-22119 for the new bug report which tracks the bitbucket (and other) private repository authentication problem. The bug where we're having this conversation is fixed, and hiding another bug report inside it may confuse others and make it less likely the bug will be fixed.

            Show
            markewaite Mark Waite added a comment - - edited Refer to JENKINS-22119 for the new bug report which tracks the bitbucket (and other) private repository authentication problem. The bug where we're having this conversation is fixed, and hiding another bug report inside it may confuse others and make it less likely the bug will be fixed.
            Hide
            markewaite Mark Waite added a comment -

            A pull request from Alexander Link added a new syntax to more precisely specify branches, without breaking compatibility with existing uses. That is available in git-client-plugin 1.10.2 and in git-plugin 2.2.5.

            Show
            markewaite Mark Waite added a comment - A pull request from Alexander Link added a new syntax to more precisely specify branches, without breaking compatibility with existing uses. That is available in git-client-plugin 1.10.2 and in git-plugin 2.2.5.

              People

              • Assignee:
                ndeloof Nicolas De Loof
                Reporter:
                sgw_aki Akihiro Sagawa
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: