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

"git remote prune" failures for alternate, ssh:// repositories

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • git-plugin
    • None
    • Ubuntu Lucid

    Description

      Version 1.1.6 works as expected. 1.1.8 now fails when running git remote prune. It might be significant that the repository in question is the preview server Git publisher pushes to and not the origin. 

       
Checkout:workspace / /var/lib/jenkins/jobs/proj-trunk/workspace - hudson.remoting.LocalChannel@5240f1d3
Using strategy: Default
Last Built Revision: Revision 51113a2f81f67645291ca381a8bc32f5cb0ebf47 (origin/master)
Checkout:wdl / /var/lib/jenkins/jobs/proj-trunk/workspace/wdl - hudson.remoting.LocalChannel@5240f1d3
Pruning obsolete local branches
FATAL: Error performing command: git remote prune platinum
Command "git remote prune platinum" returned status code 128: fatal: 'platinum' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

hudson.plugins.git.GitException: Error performing command: git remote prune platinum
Command "git remote prune platinum" returned status code 128: fatal: 'platinum' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

      This account uses SSH public-key auth and works normally in all other cases, including after reverting to 1.1.6.

      Attachments

        Activity

          Descending order - Click to sort in ascending order
          dogfood dogfood added a comment -

          Integrated in plugins_git-plugin #129
          [FIXED JENKINS-9661] Added a check to make sure we actually have the remote defined locally before we prune it.

          Andrew Bayer : d6dc41c4992adeea20cc385e5681b770ea57f01c
          Files :

          • src/main/java/hudson/plugins/git/GitAPI.java
          dogfood dogfood added a comment - Integrated in plugins_git-plugin #129 [FIXED JENKINS-9661] Added a check to make sure we actually have the remote defined locally before we prune it. Andrew Bayer : d6dc41c4992adeea20cc385e5681b770ea57f01c Files : src/main/java/hudson/plugins/git/GitAPI.java
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          src/main/java/hudson/plugins/git/GitAPI.java
          http://jenkins-ci.org/commit/git-plugin/d6dc41c4992adeea20cc385e5681b770ea57f01c
          Log:
          [FIXED JENKINS-9661] Added a check to make sure we actually have the remote defined locally before we prune it.

          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/d6dc41c4992adeea20cc385e5681b770ea57f01c Log: [FIXED JENKINS-9661] Added a check to make sure we actually have the remote defined locally before we prune it.
          abayer Andrew Bayer added a comment -

          'k, the publisher doesn't need to have the repo it's pushing to defined in the local repo as a remote - it can do it on the fly, so it'd work anyway. For now as a quick workaround, try manually adding platinum as a remote to the local repo. Longer term, I'll have a fix in the next release that makes sure not to call prune if the remote doesn't actually exist in the local repo.

          abayer Andrew Bayer added a comment - 'k, the publisher doesn't need to have the repo it's pushing to defined in the local repo as a remote - it can do it on the fly, so it'd work anyway. For now as a quick workaround, try manually adding platinum as a remote to the local repo. Longer term, I'll have a fix in the next release that makes sure not to call prune if the remote doesn't actually exist in the local repo.
          acdha acdha added a comment -

          Hmm, currently just one. Git publisher is defined to use the other remote ("platinum") by name and it appears to have worked with 1.1.6 ("Pushing HEAD to branch master at repo platinum") even though "git remote show" shows only "origin".

          git branch -r does show a reference for the remote, however:

          platinum/master

          acdha acdha added a comment - Hmm, currently just one. Git publisher is defined to use the other remote ("platinum") by name and it appears to have worked with 1.1.6 ("Pushing HEAD to branch master at repo platinum") even though "git remote show" shows only "origin". git branch -r does show a reference for the remote, however: platinum/master
          abayer Andrew Bayer added a comment -

          Hrm. In the git repo in the workspace, are there two remotes defined, or just origin?

          abayer Andrew Bayer added a comment - Hrm. In the git repo in the workspace, are there two remotes defined, or just origin?
          acdha acdha added a comment - - edited

          Sanitized project config.xml (internal hostnames converted to example.org)

          acdha acdha added a comment - - edited Sanitized project config.xml (internal hostnames converted to example.org)
          abayer Andrew Bayer added a comment -

          Could be - any chance you could attach your job's config.xml?

          abayer Andrew Bayer added a comment - Could be - any chance you could attach your job's config.xml?

          People

            abayer Andrew Bayer
            acdha acdha
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: