Details

    • Type: Bug
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.342 with git plugin 0.8
    • Similar Issues:

      Description

      There is no 'Push GIT tags back to origin repository' post-build action (as described on the plugin page), just 'Push Merges back to origin'. But tags don't get pushed back automatically either.

        Attachments

          Activity

          eris eris created issue -
          Hide
          woodstock3368 woodstock3368 added a comment -

          http://github.com/bruyeron/Hudson-GIT-plugin/commit/7cd28e8f854507037cc333097016f6ea44aaa289 would resolve this issue. How do you go about getting that change merged into the next release of git hudson plugin?

          Show
          woodstock3368 woodstock3368 added a comment - http://github.com/bruyeron/Hudson-GIT-plugin/commit/7cd28e8f854507037cc333097016f6ea44aaa289 would resolve this issue. How do you go about getting that change merged into the next release of git hudson plugin?
          abayer Andrew Bayer made changes -
          Field Original Value New Value
          Assignee jbq [ jbq ] abayer [ abayer ]
          Hide
          abayer Andrew Bayer added a comment -

          I'd say the right approach here would be to add a post-build action for pushing tags back, or better yet, to expand the "push merges" action to be more configurable, so that you can push back just tags, or merges, or changes without there having been merges, etc. I'll take a look.

          Show
          abayer Andrew Bayer added a comment - I'd say the right approach here would be to add a post-build action for pushing tags back, or better yet, to expand the "push merges" action to be more configurable, so that you can push back just tags, or merges, or changes without there having been merges, etc. I'll take a look.
          Hide
          abayer Andrew Bayer added a comment -

          About to make a run at this, with the intent of including an expanded GitPublisher in the next release.

          Show
          abayer Andrew Bayer added a comment - About to make a run at this, with the intent of including an expanded GitPublisher in the next release.
          Hide
          dogfood dogfood added a comment -

          Integrated in plugins_hudson-git-plugin #8
          JENKINS-5371 Final part of rewrite of GitPublisher, adding support for pushing tags and branches

          Andrew Bayer :
          Files :

          • src/main/resources/hudson/plugins/git/GitPublisher/help-pushMerge.html
          • src/main/webapp/gitPublisher.html
          • src/main/resources/hudson/plugins/git/GitPublisher/help-branchesToPush.html
          • src/main/resources/hudson/plugins/git/GitPublisher/help-tagsToPush.html
          Show
          dogfood dogfood added a comment - Integrated in plugins_hudson-git-plugin #8 JENKINS-5371 Final part of rewrite of GitPublisher, adding support for pushing tags and branches Andrew Bayer : Files : src/main/resources/hudson/plugins/git/GitPublisher/help-pushMerge.html src/main/webapp/gitPublisher.html src/main/resources/hudson/plugins/git/GitPublisher/help-branchesToPush.html src/main/resources/hudson/plugins/git/GitPublisher/help-tagsToPush.html
          abayer Andrew Bayer made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          abayer Andrew Bayer made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 135460 ] JNJira + In-Review [ 203496 ]
          Hide
          dantliff David Antliff added a comment -

          This isn't really fixed in my opinion - the plugin page still mentions the non-existent option, and the GitPublisher plugin doesn't have a way to push all tags - it can only push tags that can be explicitly named, so it's not useful for dynamically named tags that Jenkins doesn't know about.

          Show
          dantliff David Antliff added a comment - This isn't really fixed in my opinion - the plugin page still mentions the non-existent option, and the GitPublisher plugin doesn't have a way to push all tags - it can only push tags that can be explicitly named, so it's not useful for dynamically named tags that Jenkins doesn't know about.
          Hide
          dantliff David Antliff added a comment -

          Please reconsider this issue in light of my earlier comment.

          Show
          dantliff David Antliff added a comment - Please reconsider this issue in light of my earlier comment.
          dantliff David Antliff made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          bertr Bert Roos added a comment -

          Still quite confusing. The help text for "Create a tag for every build" of the Jenkins Git Plugin says this:

          Create a tag in the workspace for every build to unambiguously mark the commit that was built. You can combine this with Git publisher to push the tags to the remote repository.

          But the Git publisher has no option to push all tags. After a long internet search, I decided to go with just the Git publisher plug in.

          Show
          bertr Bert Roos added a comment - Still quite confusing. The help text for "Create a tag for every build" of the Jenkins Git Plugin says this: Create a tag in the workspace for every build to unambiguously mark the commit that was built. You can combine this with Git publisher to push the tags to the remote repository. But the Git publisher has no option to push all tags. After a long internet search, I decided to go with just the Git publisher plug in.
          jrp jrp made changes -
          Rank Ranked higher
          jrp jrp made changes -
          Comment [ I am another person who is the 'bacon' in our little dog's breakfast of this problem:

          I'm assuming this bug hasn't been silently closed in some other place with a non-obvious but perfectly acceptable fix that I couldn't find.

          * The documented feature doesn't show up in the product, so there is no way this is not a legitimate bug.

          * git publisher functionality a priori isn't coherent or commensurate,

          * * Even if you want to push tihs to publisher, it's also the right thing here, and it not being where it belongs is a bit of incomprehensible crazy-sauce.

          The workaround (which I guess would be explicitly calling git push yourself in script) is blinkered for plenty of cases, including mine.
          Why is this not a real bug being owned by someone actually working on it, pushing towards fix instantaneously and then making the slightly embarrassed 'oops, yeah this was dumb, sorry for the delay but my cats all died from cancer during the testing of my next major project: a 240V 3phase catnip igniter, and I've been in a bit of a funk' sort of apology for the inconvenience?

          I mean, has this thing really been not working for 6 years?

          Is there another person who should be working on it, maybe, or an escalation path it can undergo? I don't know how tihngs work around here, I'm just fascinated by what is going on.

          Or, I suppose, you could just remove the functionality from the documentation like a wimp.

          Perhaps maybe my expectations are incorrectly set: is Atlassian not a real company? Or do they not have real people who own and are responsible for this? Or, is this an loosely supported open source project with few actual people working on it: I mean, should I be like grinding through your code and fixing the degeneracy? Is that what's expected? ]

            People

            • Assignee:
              abayer Andrew Bayer
              Reporter:
              eris eris
            • Votes:
              6 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated: