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

git tag cannot be disabled overrides the existing version

    Details

    • Similar Issues:

      Description

      git describe depends on the last tag. When the plugin runs git tag, it damages the repo's idea of what the version is. git tag should be optional.

        Attachments

          Issue Links

            Activity

            Hide
            bvakili bvakili added a comment -

            I'm submitting this patch for this issue which will add an option to Git SCM plugin to disable auto tagging.

            This option appears as a checkbox (under 'Advanced'). It is disabled by default (i.e. keeps tagging enabled by default to match Hudson's existing behavior). All other changes involve centralizing the tagging code so that it can be enabled/disabled in one place.

            Once enabled, subsequent builds will skip the 'git tag' operation.

            Cheers!

            Show
            bvakili bvakili added a comment - I'm submitting this patch for this issue which will add an option to Git SCM plugin to disable auto tagging. This option appears as a checkbox (under 'Advanced'). It is disabled by default (i.e. keeps tagging enabled by default to match Hudson's existing behavior). All other changes involve centralizing the tagging code so that it can be enabled/disabled in one place. Once enabled, subsequent builds will skip the 'git tag' operation. Cheers!
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            I think the only tweak I'd made is to flip the option to positive, not negative.

            That is, on the UI, you'd say "[x] tag every build automatically" as opposed to "[ ] disable automatic git tag", to avoid double negation.

            Note that the implementation has to be done with the negative disableAutoTagging switch for a data compatibility reason

            Show
            kohsuke Kohsuke Kawaguchi added a comment - I think the only tweak I'd made is to flip the option to positive, not negative. That is, on the UI, you'd say " [x] tag every build automatically" as opposed to "[ ] disable automatic git tag", to avoid double negation. Note that the implementation has to be done with the negative disableAutoTagging switch for a data compatibility reason
            Hide
            bvakili bvakili added a comment -

            As per Kohsuke's request, I've flipped the option to positive instead of negative. Please use this newer patch (JIRA-JENKINS-5676-2.diff).

            It is now 'Tag every build automatically' and defaults to true (checked). The code and help text were also updated accordingly.

            Cheers!

            Show
            bvakili bvakili added a comment - As per Kohsuke's request, I've flipped the option to positive instead of negative. Please use this newer patch (JIRA- JENKINS-5676 -2.diff). It is now 'Tag every build automatically' and defaults to true (checked). The code and help text were also updated accordingly. Cheers!
            Hide
            markrushakoff MarkRushakoff added a comment -

            I came across this issue yesterday when I was trying to generate some files with names that had the output of git-describe, and of course they were using the hudson-build-# tag instead of my tags.

            There is a valid workaround until the patch is integrated into the plugin. Since at least version 1.5.6.6, git-describe has had a --match option that "can be used to avoid leaking private tags made from the repository".

            By using the following pattern:

            git describe --match="[^(hudson)].*"
            

            I was able to get the desired output from git-describe that ignored the Hudson tags and used the tags I have defined.

            Show
            markrushakoff MarkRushakoff added a comment - I came across this issue yesterday when I was trying to generate some files with names that had the output of git-describe, and of course they were using the hudson-build-# tag instead of my tags. There is a valid workaround until the patch is integrated into the plugin. Since at least version 1.5.6.6, git-describe has had a --match option that "can be used to avoid leaking private tags made from the repository". By using the following pattern: git describe --match="[^(hudson)].*" I was able to get the desired output from git-describe that ignored the Hudson tags and used the tags I have defined.
            Hide
            cll cll added a comment - - edited
            git describe --match="[^(hudson)].*"
            

            The output from "git tag" is ordered by name and not by the most recent tags. I suppose "git describe --match" uses this order for matching..?!
            However, in my case i don't get the right tag description. I need a option to disable auto tagging...

            Show
            cll cll added a comment - - edited git describe --match="[^(hudson)].*" The output from "git tag" is ordered by name and not by the most recent tags. I suppose "git describe --match" uses this order for matching..?! However, in my case i don't get the right tag description. I need a option to disable auto tagging...
            Hide
            bvakili bvakili added a comment -

            Mark, unfortunately I'd have to modify hundreds of build scripts at work to use the '--match' option you've proposed. So, in my case, it's not a viable workaround for me

            I'd rather fix things change in one place (i.e. the Hudson git plugin) instead.

            We've had the patch (attached to this ticket) working for months now. Are there any perceived problems with integrating it into an upcoming release?

            Show
            bvakili bvakili added a comment - Mark, unfortunately I'd have to modify hundreds of build scripts at work to use the '--match' option you've proposed. So, in my case, it's not a viable workaround for me I'd rather fix things change in one place (i.e. the Hudson git plugin) instead. We've had the patch (attached to this ticket) working for months now. Are there any perceived problems with integrating it into an upcoming release?
            Hide
            dogfood dogfood added a comment -

            Integrated in plugins_git-plugin #84
            [FIXED JENKINS-5676] Added an advanced option to skip the internal tagging.

            Andrew Bayer :
            Files :

            • src/main/webapp/help-skipTag.html
            • src/test/java/hudson/plugins/git/GitSCMTest.java
            • src/main/java/hudson/plugins/git/GitSCM.java
            • src/main/resources/hudson/plugins/git/GitSCM/config.jelly
            Show
            dogfood dogfood added a comment - Integrated in plugins_git-plugin #84 [FIXED JENKINS-5676] Added an advanced option to skip the internal tagging. Andrew Bayer : Files : src/main/webapp/help-skipTag.html src/test/java/hudson/plugins/git/GitSCMTest.java src/main/java/hudson/plugins/git/GitSCM.java src/main/resources/hudson/plugins/git/GitSCM/config.jelly
            Hide
            eguess74 eguess74 added a comment - - edited

            There is a bug introduced with this change. By default the state of "Skip internal tagging" is unmarked - but no tagging happening. We actually use these tags extensively, so they are critical to our release process. Could you, please, fix it?
            Git plugin 1.1.5

            Show
            eguess74 eguess74 added a comment - - edited There is a bug introduced with this change. By default the state of "Skip internal tagging" is unmarked - but no tagging happening. We actually use these tags extensively, so they are critical to our release process. Could you, please, fix it? Git plugin 1.1.5
            Hide
            abayer Andrew Bayer added a comment -

            Hi -

            Are you sure it's not tagging? In my tests, I'm seeing tags in the default case - it's not logging that it's tagging currently, but the actual tags are there. They are formatted as "jenkins-[job]-[buildnumber]" now.

            Show
            abayer Andrew Bayer added a comment - Hi - Are you sure it's not tagging? In my tests, I'm seeing tags in the default case - it's not logging that it's tagging currently, but the actual tags are there. They are formatted as "jenkins- [job] - [buildnumber] " now.
            Hide
            eguess74 eguess74 added a comment -

            My bad.
            I was waiting for the tag format as hudson-[job]...
            Now absence of log saying that it is tagging with tag bla-bla confused me even more.

            So, while i will change the script to expect the tag in new jenkins format, could you please add logging of this tagging step to the build log?

            Thanks!!

            Show
            eguess74 eguess74 added a comment - My bad. I was waiting for the tag format as hudson- [job] ... Now absence of log saying that it is tagging with tag bla-bla confused me even more. So, while i will change the script to expect the tag in new jenkins format, could you please add logging of this tagging step to the build log? Thanks!!

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                rcolocke rcolocke
              • Votes:
                9 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: