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

check in of a bad .gitmodules files causes the job to fail until manual intervention

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Minor Minor
    • git-plugin
    • None
    • Jenkins 2.46.3 with git plugin

      Steps to reproduce:

      Setup a basic job which clones a git repo with submodules.

      Commit some faulty text in the .gitmodules file (in our case, it was an unresolved conflict i.e. <<<<<<< >>>>>> lines)

      20:40:22  > git fetch --tags --progress git@acme.com:acme/acme.git +refs/heads/*:refs/remotes/origin/* +refs/pull/*:refs/remotes/origin/pr/*
      20:40:22 ERROR: Error fetching remote repo 'origin'
      20:40:22 hudson.plugins.git.GitException: Failed to fetch from git@github.mv.usa.alcatel.com:VCA/VCA.git
      20:40:22 	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:809)
      20:40:22 	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1076)
      20:40:22 	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1107)
      20:40:22 	at hudson.scm.SCM.checkout(SCM.java:496)
      20:40:22 	at hudson.model.AbstractProject.checkout(AbstractProject.java:1281)
      20:40:22 	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
      20:40:22 	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
      20:40:22 	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
      20:40:22 	at com.tikal.jenkins.plugins.multijob.MultiJobBuild$MultiJobRunnerImpl.run(MultiJobBuild.java:136)
      20:40:22 	at hudson.model.Run.execute(Run.java:1728)
      20:40:22 	at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java:73)
      20:40:22 	at hudson.model.ResourceController.execute(ResourceController.java:98)
      20:40:22 	at hudson.model.Executor.run(Executor.java:405)
      20:40:22 Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@acme.com:acme/acme.git +refs/heads/*:refs/remotes/origin/* +refs/pull/*:refs/remotes/origin/pr/*" returned status code 128:
      20:40:22 stdout: 
      20:40:22 stderr: fatal: bad config file line 1 in /var/lib/jenkins/jobs/acmejob/workspace/.gitmodules
      20:40:22 
      20:40:22 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1903)
      20:40:22 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1622)
      20:40:22 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:71)
      20:40:22 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:348)
      20:40:22 	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:807)
      20:40:22 	... 12 more
      20:40:22 ERROR: null
      20:40:22 Performing Post build task...
      20:40:22 Could not match :Build was aborted  : False
      20:40:22 Logical operation result is FALSE

      The issue is that, after committing a fix to .gitmodules file, the issue still happens on all subsequent jobs using the same workspace.

       

      I am aware of the "wipe repo and force clone" option, however is there a way for jenkins git plugin default behaviour not to exhibit this ?

          [JENKINS-44802] check in of a bad .gitmodules files causes the job to fail until manual intervention

          Mark Waite added a comment -

          Damaging the content of critical git files is really not something that the plugin can handle more than it already did (by telling you that the content of the file was bad).

          There is ongoing work to better handle submodule structural changes in a workspace.  Refer to JENKINS-43977, JENKINS-41553 and JENKINS-38860.

          Mark Waite added a comment - Damaging the content of critical git files is really not something that the plugin can handle more than it already did (by telling you that the content of the file was bad). There is ongoing work to better handle submodule structural changes in a workspace.  Refer to JENKINS-43977 , JENKINS-41553 and JENKINS-38860 .

          Nicolas Ochem added a comment -

          Thanks for the prompt reply.

          I just want to stress that every subsequent job will not run if any job has a faulty gitmodule file. Also, unlike .git folder, .gitmodules file is part of the repo (just like .gitignore).

          In our context, it gave an unprivileged user creating a pull request, ability to break the job for everyone else, including mainline jobs. I don't see anything in the 3 referenced bugs addressing this.

          Nicolas Ochem added a comment - Thanks for the prompt reply. I just want to stress that every subsequent job will not run if any job has a faulty gitmodule file. Also, unlike .git folder, .gitmodules file is part of the repo (just like .gitignore). In our context, it gave an unprivileged user creating a pull request, ability to break the job for everyone else, including mainline jobs. I don't see anything in the 3 referenced bugs addressing this.

          Mark Waite added a comment -

          As far as I can tell, the condition you're describing matches my interpretation of those other 3 bugs.  

          They each phrase it slightly differently, but come to a the premise that a workspace which contains submodules is not set to the precise condition that would match a fresh clone of the repository with a fresh "git submodule update --init" at the start of each run of that job.  I think that's the same condition you're describing.  Once the workspace gitmodules file has been damaged by a job, later checkouts in that workspace don't "undamage" it, even though the damage to the origin repository has been repaired.

          Mark Waite added a comment - As far as I can tell, the condition you're describing matches my interpretation of those other 3 bugs.   They each phrase it slightly differently, but come to a the premise that a workspace which contains submodules is not set to the precise condition that would match a fresh clone of the repository with a fresh "git submodule update --init" at the start of each run of that job.  I think that's the same condition you're describing.  Once the workspace gitmodules file has been damaged by a job, later checkouts in that workspace don't "undamage" it, even though the damage to the origin repository has been repaired.

            Unassigned Unassigned
            nicolas_o Nicolas Ochem
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: