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

Git Publisher fails to push tags with REJECTED_OTHER_REASON

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-client-plugin
    • None
    • Jenkins 2.16
      Git Plugin 2.5.3
      Git Client Plugin 1.19.7
      OS: Centos 6.7
      Java(TM) SE Runtime Environment (build 1.7.0_75-b13)

      Git Publisher Post-Build step fails to push tags.

      As outlined here http://stackoverflow.com/questions/35995736/jenkins-git-publisher-unable-to-push-tags/36575057, downgrading to earlier versions of these plugins makes this work:

      • Git plugin : 2.4.0 works, 2.5.3 does not work
      • Git client plugin: 1.18.0 works, 1.19.7 does not work
        (probably versions in between do not work either. I did not test any other combinations)

      Steps to reproduce:

      1. Create a job that clones a github repo, use credentials with a key for a user that has push privileges in github. Additional behaviors: checkout to local branch "master", Wipe and force clone.
      2. Add a Git Publisher step, add tag with arbitrary name, check create and update checkboxes
      3. No other job configuration items are necessary

      With versions labeled "does not work" above, job fails with the following error:

      *Wiping out workspace first.
      Cloning the remote Git repository
      remote: Counting objects
      Receiving objects
      Resolving deltas
      Updating references
      Checking out Revision be5c9260a46cefcd37a5ef23ed04d112dc4e4c47 (refs/remotes/origin/master)
      Pushing tag test-tag to repo origin
      RefSpec is "refs/tags/test-tag:refs/heads/test-tag".
      Opening connection
      Counting objects
      Finding sources
      Writing objects
      ERROR: Failed to push tag test-tag to origin
      hudson.plugins.git.GitException: failed REJECTED_OTHER_REASON for 'refs/tags/test-tag:refs/heads/test-tag' refspec 'test-tag' to git@github.com:bla.bla.bla.git
      at org.jenkinsci.plugins.gitclient.JGitAPIImpl$9.execute(JGitAPIImpl.java:1870)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
      at hudson.remoting.UserRequest.perform(UserRequest.java:121)
      at hudson.remoting.UserRequest.perform(UserRequest.java:49)
      at hudson.remoting.Request$2.run(Request.java:324)
      at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      at hudson.remoting.Engine$1$1.run(Engine.java:63)
      at java.lang.Thread.run(Thread.java:745)
      at ......remote call to tc-docker-swarm-01-5209d3c4(Native Method)
      at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
      at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
      at hudson.remoting.Channel.call(Channel.java:781)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:606)
      at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
      at com.sun.proxy.$Proxy66.execute(Unknown Source)
      at hudson.plugins.git.GitPublisher.perform(GitPublisher.java:295)
      at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
      at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
      at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)
      at hudson.model.Build$BuildExecution.post2(Build.java:185)
      at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:665)
      at hudson.model.Run.execute(Run.java:1745)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      at hudson.model.ResourceController.execute(ResourceController.java:98)
      at hudson.model.Executor.run(Executor.java:404)
      Build step 'Git Publisher' marked build as failure*

      With the older versions specified, tag is pushed successfully.

          [JENKINS-37120] Git Publisher fails to push tags with REJECTED_OTHER_REASON

          Alexander Komarov added a comment - - edited

          FYI to anyone having this issue: As a workaround I am using the ssh-agent plugin and direct shell commands to make/push tags. Something like this:

          #If using ssh, this is important because you'll get a cryptic Host Key Verification Failed without it (unless your master has the key for every slave in its known_hosts)
          export GIT_SSH_COMMAND="ssh -oStrictHostKeyChecking=no"

          git tag -fa "TAG_NAME" -m "Description"
          git push origin :refs/tags/TAG_NAME # Delete current upstream tag
          git push origin master --tags

          Alexander Komarov added a comment - - edited FYI to anyone having this issue: As a workaround I am using the ssh-agent plugin and direct shell commands to make/push tags. Something like this: #If using ssh, this is important because you'll get a cryptic Host Key Verification Failed without it (unless your master has the key for every slave in its known_hosts) export GIT_SSH_COMMAND="ssh -oStrictHostKeyChecking=no" git tag -fa "TAG_NAME" -m "Description" git push origin :refs/tags/TAG_NAME # Delete current upstream tag git push origin master --tags

          gilesbaxter added a comment -

          I'm also seeing the same issue with

          Jenkins 2.32.2 and 1.651.3

          git-plugin 3,1,0

          git-client-plugin 2.4.0

          pushing to Team Foundation Server 15.105.25910.0

           

          I was able to get it to work by modifying and recompiling the git-client.jar from the git-client-plugin.

          It seems to me that the RefSpec being pushed is incorrect - it shouldn't be "/refs/tags/<tag_name>:/refs/heads/<tag_name>" but instead "/refs/tags/<tag_name>:/refs/tags/<tag_name>".

          So in org.jenkinsci.plugins.gitclient.JGitAPIImpl.java, I changed line 1837 to

          if (specs[spec - 1].startsWith("refs/tags/")) {

              specs[spec] = specs[spec - 1];

              break;

          }

          And now the RefSpec used is "/refs/tags/<tag_name>:/refs/tags/<tag_name>", and the push goes through. It seems this section of code was questionable to begin with. I'm not sure my solution is good in the bigger picture. but something like this should probably be done...

          gilesbaxter added a comment - I'm also seeing the same issue with Jenkins 2.32.2 and 1.651.3 git-plugin 3,1,0 git-client-plugin 2.4.0 pushing to Team Foundation Server 15.105.25910.0   I was able to get it to work by modifying and recompiling the git-client.jar from the git-client-plugin. It seems to me that the RefSpec being pushed is incorrect - it shouldn't be "/refs/tags/<tag_name>:/refs/ heads /<tag_name>" but instead "/refs/tags/<tag_name>:/refs/ tags /<tag_name>". So in org.jenkinsci.plugins.gitclient.JGitAPIImpl.java, I changed line 1837 to if (specs [spec - 1] .startsWith("refs/tags/")) {     specs [spec] = specs [spec - 1] ;     break; } And now the RefSpec used is "/refs/tags/<tag_name>:/refs/ tags /<tag_name>", and the push goes through. It seems this section of code was questionable to begin with. I'm not sure my solution is good in the bigger picture. but something like this should probably be done...

          gilesbaxter added a comment -

          Since this issue came up after version 1.8.0, I believe it's a regression introduced by this fix: https://github.com/jenkinsci/git-client-plugin/commit/c9e96d48062e6a8ed11857f0f00a00c86ec76c98

          which was included after 1.8.0

          gilesbaxter added a comment - Since this issue came up after version 1.8.0, I believe it's a regression introduced by this fix: https://github.com/jenkinsci/git-client-plugin/commit/c9e96d48062e6a8ed11857f0f00a00c86ec76c98 which was included after 1.8.0

          gilesbaxter added a comment -

          A workaround that still allows you to use the Git Publisher is to fully specify your tag refs, i.e., refs/tags/<tag_name> instead of just <tag_name> in the Git Publisher text box. This avoids the problem code altogether.

          gilesbaxter added a comment - A workaround that still allows you to use the Git Publisher is to fully specify your tag refs, i.e., refs/tags/<tag_name> instead of just <tag_name> in the Git Publisher text box. This avoids the problem code altogether.

          Ross added a comment -

          We are still encountering this issue using jgit in a freestyle build that runs on a slave node on Jenkins 2.274 using Git plugin 4.5.1 and Git client plugin 3.6.0.

          Specifying refs/tags/<tag_name> instead of <tag_name> in the Git Publisher option for "Tag to push" worked for us. Thanks gilesbaxter!

          Ross added a comment - We are still encountering this issue using jgit in a freestyle build that runs on a slave node on Jenkins 2.274 using Git plugin 4.5.1 and Git client plugin 3.6.0. Specifying refs/tags/<tag_name> instead of <tag_name> in the Git Publisher option for "Tag to push" worked for us. Thanks gilesbaxter !

          Ross added a comment -

          We've run into an issue with the refs/tags/xxx workaround. It appears that due to the core issue (wrong tag refspec as described by gilesbaxter), the tags are created incorrectly on remote. See this related Stack Overflow post which details funky behavior with git describe.

          Can anyone advise on if a refspec fix like mentioned above is a correct approach? If so, I'm happy to help with the change to get this corrected. Thanks!

          Ross added a comment - We've run into an issue with the refs/tags/xxx workaround. It appears that due to the core issue (wrong tag refspec as described by gilesbaxter ), the tags are created incorrectly on remote. See this related Stack Overflow post which details funky behavior with git describe . Can anyone advise on if a refspec fix like mentioned above is a correct approach? If so, I'm happy to help with the change to get this corrected. Thanks!

            Unassigned Unassigned
            akom Alexander Komarov
            Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: