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

Git Plugin only scans refs/heads on multibranch scan

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.75
      git-plugin 3.5.1
    • Similar Issues:

      Description

      Because this was completely breaking my build environment, I was able to track down the issue to the following file: https://github.com/jenkinsci/git-plugin/blob/git-3.5.1/src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

      Broken on sha a4febc060a23740816d660915b9fe0a7a6ffdcf6

      Working on sha d7c3ece2553cf0494a56c766f62a6c9f340bbe4c

      To get it to work in my environment, I reverted this one file to the previous sha and built the plugin locally. Installed on my Jenkins instance and the issue was fixed.

       

      Issue:

      For multibranch projects- not tested on single branch projects

      Basically, when listing remotes during branch discovery, it forces the '-h' option for git ls-remotes and ignores any refspec given.

      For example, I give the refspec '+refs/collab/:refs/remotes/origin/collab/' but it only lists (and therefore filters) remotes for '+refs/heads/:refs/remotes/origin/heads/'

      Our org needs the custom refs location because that is how we automate code reviews.  On version 3.4.1 of the plugin, this refspec worked just fine.  On version 3.5.0, it broke and deleted all the collab branches.

      Please let me know if you need any additional details.  I would submit a PR but, my Java is weak.  Thank you, kindly!

       

       

       

        Attachments

          Issue Links

            Activity

            Hide
            yunikkk Dmitry Yunitsky added a comment -

            Hello, seems that we are stuck with the exact same issue. 

            We build pull-requests that are stored under "refs/pull-requests/*/merge" with our Bitbucket server. Now we use 3.4.1 plugin version and cannot update to 3.7.0 where the flow is broken. Is there any possible workaround or solution for that? 

            Thanks.

            Show
            yunikkk Dmitry Yunitsky added a comment - Hello, seems that we are stuck with the exact same issue.  We build pull-requests that are stored under "refs/pull-requests/*/merge" with our Bitbucket server. Now we use 3.4.1 plugin version and cannot update to 3.7.0 where the flow is broken. Is there any possible workaround or solution for that?  Thanks.
            Hide
            fbaeuerle Florian Bäuerle added a comment -

            Dmitry Yunitsky, Stephen Catt, Konstantin Ryakhovskiy for me this issue is fixed with git-plugin 3.9.0

            There is a new option called "Discover other refs".

             

            I've already closed #45990 which sounded very similar to me. Could you please confirm that the issue is fixed for you as well?

            Show
            fbaeuerle Florian Bäuerle added a comment - Dmitry Yunitsky , Stephen Catt , Konstantin Ryakhovskiy  for me this issue is fixed with git-plugin 3.9.0 There is a new option called "Discover other refs".   I've already closed #45990 which sounded very similar to me. Could you please confirm that the issue is fixed for you as well?
            Hide
            scatt Stephen Catt added a comment -

            Florian Bäuerle,

            I installed the update over the weekend.  Though the "discover other refs" plugin will now successfully scan for the branches, it won't build them.  It kept throwing an error that it could not find a revision to build.  I was looking through the git plugin repo and it looks like they have not implemented telescoping support yet, which may be the issue.  From what I could tell, this i tracked in JENKINS-51134

            So, hopefully, the next version will fix it.

             

            Show
            scatt Stephen Catt added a comment - Florian Bäuerle , I installed the update over the weekend.  Though the "discover other refs" plugin will now successfully scan for the branches, it won't build them.  It kept throwing an error that it could not find a revision to build.  I was looking through the git plugin repo and it looks like they have not implemented telescoping support yet, which may be the issue.  From what I could tell, this i tracked in JENKINS-51134 So, hopefully, the next version will fix it.  
            Hide
            fbaeuerle Florian Bäuerle added a comment -

            Stephen Catt

            Thanks. Correct - looks like I was a bit too overzealously closing the other Issue.

            I get this message:
            ERROR: Could not determine exact tip revision of pull/2212/merge; falling back to nondeterministic checkout

            In the end, the correct commit is checked out but as soon as the actual pipeline script is executed on a node, the job fails with java.nio.file.NoSuchFileException. The Dockerfile cannot be found, which makes sense, because there is absolutetly nothing created on the slave (not even a workdir is being created).

            Show
            fbaeuerle Florian Bäuerle added a comment - Stephen Catt Thanks. Correct - looks like I was a bit too overzealously closing the other Issue. I get this message: ERROR: Could not determine exact tip revision of pull/2212/merge; falling back to nondeterministic checkout In the end, the correct commit is checked out but as soon as the actual pipeline script is executed on a node, the job fails with java.nio.file.NoSuchFileException. The Dockerfile cannot be found, which makes sense, because there is absolutetly nothing created on the slave (not even a workdir is being created).
            Hide
            nijtmans Jan Nijtmans added a comment -

            Just encountered this bug in our environment as well.  What I see in our log is:

                git rev-parse refs/pull-requests-2^{commit} # timeout=10

            which should have been:

                git rev-parse refs/pull-requests/2/merge^{commit} # timeout=10

            So it looks like the "rev-parse" command is constructed wrong: The translated name is used in stead of the internal GIT name. for the ref.

             

            Hope this helps,

                      Jan Nijtmans

            Show
            nijtmans Jan Nijtmans added a comment - Just encountered this bug in our environment as well.  What I see in our log is:     git rev-parse refs/pull-requests-2^{commit} # timeout=10 which should have been:     git rev-parse refs/pull-requests/2/merge^{commit} # timeout=10 So it looks like the "rev-parse" command is constructed wrong: The translated name is used in stead of the internal GIT name. for the ref.   Hope this helps,           Jan Nijtmans

              People

              • Assignee:
                stephenc Stephen Connolly
                Reporter:
                scatt Stephen Catt
              • Votes:
                5 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated: