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

cannot use the "pass-through git commit that was built" parameter with triggered jobs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      64-bit linux
    • Similar Issues:

      Description

      I am trying to distribute my test suite jobs to run in parallel by kicking them off from a "master" build job which triggers other jobs. I want all test suites to run against a consistent state of my repository, so I added the "pass-through git commit that was built" parameter. But this causes all sub-jobs to fail with the error message below. This is blocking me from setting up jenkins jobs the way I want.

      I suppose this could be a misconfiguration. But my sub-jobs run fine when they are run individually, and I don't see any git parameter I can add in my sub-job configuration. Ideally, I want the "pass-through git commit" feature to just work without any special re-configuration.

      This is related to issue JENKINS-9049, but that issue's exception is different and it's related to the Gerrit plugin (which I am not using), so I thought I should open a new issue.

      The exception is:

      Started by upstream project "Master" build number 5
      Building on master
      Checkout:workspace / /data/jenkins/jobs/Master-unit_tests/workspace - hudson.remoting.LocalChannel@126be4cc
      Using strategy: Default
      Last Built Revision: Revision 70532721cd3016b4746da4c89a9b7cc85a11bae4 (origin/master)
      Checkout:workspace / /data/jenkins/jobs/Master-unit_tests/workspace - hudson.remoting.LocalChannel@126be4cc
      Fetching changes from the remote Git repository
      Fetching upstream changes from git@git.example.com:my_project.git
      Commencing build of Revision e4d1ff0056235b827934b1d9a0352a6a8f04e286 (detached)
      Checking out Revision e4d1ff0056235b827934b1d9a0352a6a8f04e286 (detached)
      FATAL: no remote from branch name (detached)
      hudson.plugins.git.GitException: no remote from branch name (detached)
      at hudson.plugins.git.GitAPI.setupSubmoduleUrls(GitAPI.java:667)
      at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1158)
      at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1120)
      at hudson.FilePath.act(FilePath.java:758)
      at hudson.FilePath.act(FilePath.java:740)
      at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1120)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1181)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:536)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:424)
      at hudson.model.Run.run(Run.java:1375)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:145)

        Attachments

          Activity

          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Please report the version of the Git plugin.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Please report the version of the Git plugin.
          Hide
          amurray Adam Murray added a comment -

          Version 1.1.9.

          I see that 1.1.11 is now available. Is this perhaps fixed in the latest version? I will try it soon...

          Show
          amurray Adam Murray added a comment - Version 1.1.9. I see that 1.1.11 is now available. Is this perhaps fixed in the latest version? I will try it soon...
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          OK, I figured out what's going on.

          Git plugin tries to be clever about submodule handling — by which I mean we try to figure out a "better" location to check out modules.

          Imagine the situation where you have something like tree-structured repositories: at the root you have corporate central repositories that you ultimately push to, which all .gitmodules point to, then you have intermediate team local repository, which is assumed to be a non-bare repository (say, a checked out copy on a shared server accessed via SSH.) Maybe this is where you are pushing, so that you can have the changes tested by Jenkins before it hits the central. Or maybe this is where you do merge test with others.

          In anticipation of this use case, Git plugin looks at which remote repository the commit came from, and if it looks like a non-bare repository (meaning if it slooks like the team local repository above), it tries to update modules from subdirectories of this repository, assuming that it's a fully populated checked out copy.

          Note that there's a lot of heuristics and assumptions involved in this. And this code wasn't handling the case correctly if we are building a specific SHA1 (either via user-specified value, or via pass-through Git commit.) So the fix involves in making this logic a bit more robust.

          I have to say that, for my personal taste, this feels like too much heuristics from such unreliable clues, but such are the current behaviour, and we need to preserve this.

          I'm testing the fix now.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - OK, I figured out what's going on. Git plugin tries to be clever about submodule handling — by which I mean we try to figure out a "better" location to check out modules. Imagine the situation where you have something like tree-structured repositories: at the root you have corporate central repositories that you ultimately push to, which all .gitmodules point to, then you have intermediate team local repository, which is assumed to be a non-bare repository (say, a checked out copy on a shared server accessed via SSH.) Maybe this is where you are pushing, so that you can have the changes tested by Jenkins before it hits the central. Or maybe this is where you do merge test with others. In anticipation of this use case, Git plugin looks at which remote repository the commit came from, and if it looks like a non-bare repository (meaning if it slooks like the team local repository above), it tries to update modules from subdirectories of this repository, assuming that it's a fully populated checked out copy. Note that there's a lot of heuristics and assumptions involved in this. And this code wasn't handling the case correctly if we are building a specific SHA1 (either via user-specified value, or via pass-through Git commit.) So the fix involves in making this logic a bit more robust. I have to say that, for my personal taste, this feels like too much heuristics from such unreliable clues, but such are the current behaviour, and we need to preserve this. I'm testing the fix now.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          src/test/java/hudson/plugins/git/GitSCMTest.java
          http://jenkins-ci.org/commit/git-plugin/cefbb29df219a2bd9742e8e2dcb687988e56a133
          Log:
          JENKINS-10060 added a regression test case.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/test/java/hudson/plugins/git/GitSCMTest.java http://jenkins-ci.org/commit/git-plugin/cefbb29df219a2bd9742e8e2dcb687988e56a133 Log: JENKINS-10060 added a regression test case.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          src/main/java/hudson/plugins/git/GitAPI.java
          http://jenkins-ci.org/commit/git-plugin/c8c7c0afb6f997ab4b743471f49c520875e52e7e
          Log:
          [FIXED JENKINS-10060] made the handling more robust.

          See the comment in the code and in the ticket for discussion of what was going wrong and why I think this fix is a reasonable one.

          Compare: https://github.com/jenkinsci/git-plugin/compare/7219d74...c8c7c0a

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/c8c7c0afb6f997ab4b743471f49c520875e52e7e Log: [FIXED JENKINS-10060] made the handling more robust. See the comment in the code and in the ticket for discussion of what was going wrong and why I think this fix is a reasonable one. Compare: https://github.com/jenkinsci/git-plugin/compare/7219d74...c8c7c0a
          Hide
          dogfood dogfood added a comment -

          Integrated in plugins_git-plugin #207
          JENKINS-10060 added a regression test case.
          [FIXED JENKINS-10060] made the handling more robust.

          Kohsuke Kawaguchi : cefbb29df219a2bd9742e8e2dcb687988e56a133
          Files :

          • src/test/java/hudson/plugins/git/GitSCMTest.java

          Kohsuke Kawaguchi : c8c7c0afb6f997ab4b743471f49c520875e52e7e
          Files :

          • src/main/java/hudson/plugins/git/GitAPI.java
          Show
          dogfood dogfood added a comment - Integrated in plugins_git-plugin #207 JENKINS-10060 added a regression test case. [FIXED JENKINS-10060] made the handling more robust. Kohsuke Kawaguchi : cefbb29df219a2bd9742e8e2dcb687988e56a133 Files : src/test/java/hudson/plugins/git/GitSCMTest.java Kohsuke Kawaguchi : c8c7c0afb6f997ab4b743471f49c520875e52e7e Files : src/main/java/hudson/plugins/git/GitAPI.java

            People

            • Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              amurray Adam Murray
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: