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

git plugin should NOT tag every build by default

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None

      Description

      Git plugin automatically tries to add tags to my Git repository for every build (every 15 minutes or so!). that's very weird it does it automatically by default without me configuring this.
      I don't need hundreds of tags in Git repo... I suggest turning this OFF by default and allowing to configure it in Jenkins UI per build job.

        Issue Links

          Activity

          Hide
          alskor Alexey Java added a comment -

          marking as "blocker" because it's impossible to use this plugin with Jenkins unless you configure your build machine to tag all builds (which may be impossible or very undesirable for many projects)

          Show
          alskor Alexey Java added a comment - marking as "blocker" because it's impossible to use this plugin with Jenkins unless you configure your build machine to tag all builds (which may be impossible or very undesirable for many projects)
          Hide
          alskor Alexey Java added a comment -

          what's worse, the build fails in a way that does not really tell "Failed" to the Jenkins, so it keeps restarting the build job every 15 minutes even though there are no changes in GIT (instead of waiting for the manual restart).
          (I don't have "build periodically", I use "poll periodically" instead)

          Show
          alskor Alexey Java added a comment - what's worse, the build fails in a way that does not really tell "Failed" to the Jenkins, so it keeps restarting the build job every 15 minutes even though there are no changes in GIT (instead of waiting for the manual restart). (I don't have "build periodically", I use "poll periodically" instead)
          Hide
          barry_allard Barry Allard added a comment -

          +1. This is a high-priority blocker. This is seen when building a read-only github repo like git://github.com/user/project.git

          Show
          barry_allard Barry Allard added a comment - +1. This is a high-priority blocker. This is seen when building a read-only github repo like git://github.com/user/project.git
          Hide
          barry_allard Barry Allard added a comment -

          sanitized build log

          Show
          barry_allard Barry Allard added a comment - sanitized build log
          Hide
          abayer abayer added a comment -

          Barry - your issue isn't the read-only github URL. It's that you don't have the git config user.name and user.email configured for the Jenkins user. You can do that through Jenkins, either in the advanced Git config for an individual job, or globally in Manage Jenkins.

          Show
          abayer abayer added a comment - Barry - your issue isn't the read-only github URL. It's that you don't have the git config user.name and user.email configured for the Jenkins user. You can do that through Jenkins, either in the advanced Git config for an individual job, or globally in Manage Jenkins.
          Hide
          barry_allard Barry Allard added a comment -

          @abayer: You're correct. Interesting, it tries to tag the build without a user.

          {name,email}

          but it does try to tag without it configured.

          Show
          barry_allard Barry Allard added a comment - @abayer: You're correct. Interesting, it tries to tag the build without a user. {name,email} but it does try to tag without it configured.
          Hide
          alskor Alexey Java added a comment -

          is there a workaround I can use to disable tagging builds?

          Show
          alskor Alexey Java added a comment - is there a workaround I can use to disable tagging builds?
          Hide
          alskor Alexey Java added a comment -

          can I at least download the older version of this plugin somewhere (1.1.12, without the build tags)?

          btw, build tags are useless in general because all builds already have the changeset/commit info and you can recreate the build using that.

          Show
          alskor Alexey Java added a comment - can I at least download the older version of this plugin somewhere (1.1.12, without the build tags)? btw, build tags are useless in general because all builds already have the changeset/commit info and you can recreate the build using that.
          Hide
          dstine Dan Stine added a comment -

          I noticed this default behavior also. I was able to turn it off in the project-level configuration.

          Jenkins 1.448

          Configure | Source Code Management

          under Branches to build, click Advnaced

          Check the "Skip internal tag" checkbox and Save.

          Show
          dstine Dan Stine added a comment - I noticed this default behavior also. I was able to turn it off in the project-level configuration. Jenkins 1.448 Configure | Source Code Management under Branches to build, click Advnaced Check the "Skip internal tag" checkbox and Save.
          Hide
          alskor Alexey Java added a comment -

          thank you very much, Dan. this worked.

          Show
          alskor Alexey Java added a comment - thank you very much, Dan. this worked.
          Hide
          sledz Steffen Sledz added a comment -

          Can't find this checkbox in Jenkins 1.459.

          Where did it went to?

          Show
          sledz Steffen Sledz added a comment - Can't find this checkbox in Jenkins 1.459. Where did it went to?
          Hide
          owenmehegan owenmehegan added a comment -

          I agree that this behavior is annoying and should not be on by default. All of my repos now have tens or hundreds of jenkins tags that I don't care about, and running 'git tag' on them produces a pretty useless output. Can this be off by default?

          Show
          owenmehegan owenmehegan added a comment - I agree that this behavior is annoying and should not be on by default. All of my repos now have tens or hundreds of jenkins tags that I don't care about, and running 'git tag' on them produces a pretty useless output. Can this be off by default?
          Hide
          bdefore Buck D added a comment -

          Agreed with other commenters. This should be off by default and exposed in project configuration.

          Show
          bdefore Buck D added a comment - Agreed with other commenters. This should be off by default and exposed in project configuration.
          Hide
          zaytsev Yury Zaytsev added a comment -

          There is now a checkbox to make tagging optional.

          Show
          zaytsev Yury Zaytsev added a comment - There is now a checkbox to make tagging optional.
          Hide
          owenmehegan owenmehegan added a comment -

          This is not resolved - the request is for the internal tag to be disabled by default. Since this feature was introduced, anyone who doesn't want it has to manually edit ALL their build jobs and disable it.

          Show
          owenmehegan owenmehegan added a comment - This is not resolved - the request is for the internal tag to be disabled by default. Since this feature was introduced, anyone who doesn't want it has to manually edit ALL their build jobs and disable it.
          Hide
          bdefore Buck D added a comment -

          @owenmehegan is correct, the git plugin should not dictate a tagging philosophy unless the user opts into it. with lots of jenkins projects this is tedious to disable. The checkbox currently requires you to hit the 'Advanced' button under the 'Branches to build' section and then checking 'Skip internal tag'

          Show
          bdefore Buck D added a comment - @owenmehegan is correct, the git plugin should not dictate a tagging philosophy unless the user opts into it. with lots of jenkins projects this is tedious to disable. The checkbox currently requires you to hit the 'Advanced' button under the 'Branches to build' section and then checking 'Skip internal tag'
          Hide
          markewaite Mark Waite added a comment -

          The git-plugin 2.0.1 and git-client-plugin 1.6.2 do not create a tag for every build. The default setting for the "Create a tag for every build" is now off.

          Show
          markewaite Mark Waite added a comment - The git-plugin 2.0.1 and git-client-plugin 1.6.2 do not create a tag for every build. The default setting for the "Create a tag for every build" is now off.
          Hide
          markewaite Mark Waite added a comment -

          Verified that "off" is the current default for git tagging of each build.

          Show
          markewaite Mark Waite added a comment - Verified that "off" is the current default for git tagging of each build.
          Hide
          feystorm Patrick Hemmer added a comment -

          I'm using git-plugin 2.2.5 and git-client-plugin 1.10.1 and this thing is still creating tags. It doesn't push them to the remote, but it still creates them locally.

          Show
          feystorm Patrick Hemmer added a comment - I'm using git-plugin 2.2.5 and git-client-plugin 1.10.1 and this thing is still creating tags. It doesn't push them to the remote, but it still creates them locally.
          Hide
          markewaite Mark Waite added a comment -

          Patrick Hemmer I don't see this result on any of my 100+ jobs, on multiple machines.

          I use many combinations of authentication (read only, read/write, ssh keys, username/password, etc.), transport (git, ssh, https) and servers (bitbucket, github, assembla, local git server). I'm not seeing a tag per build on any of my jobs, unless the "Additional Behaviours" has been enabled to "Create a tag for every build".

          Is this happening on every job, including newly created jobs, or only on jobs which were defined prior to your upgrade to git plugin version 2 ?

          Is "Create a tag for every build" enabled in the job configuration?

          Is there anything else which might be unique or different about your configuration?

          Show
          markewaite Mark Waite added a comment - Patrick Hemmer I don't see this result on any of my 100+ jobs, on multiple machines. I use many combinations of authentication (read only, read/write, ssh keys, username/password, etc.), transport (git, ssh, https) and servers (bitbucket, github, assembla, local git server). I'm not seeing a tag per build on any of my jobs, unless the "Additional Behaviours" has been enabled to "Create a tag for every build". Is this happening on every job, including newly created jobs, or only on jobs which were defined prior to your upgrade to git plugin version 2 ? Is "Create a tag for every build" enabled in the job configuration? Is there anything else which might be unique or different about your configuration?
          Hide
          feystorm Patrick Hemmer added a comment -

          I noticed after I submitted that comment that it doesn't happen unless the git-publisher is enabled (post-build action). As soon as it's enabled, it starts generating tags of the form "jenkins-$

          {project}

          -$

          {build_number}

          -SUCCESS"

          Show
          feystorm Patrick Hemmer added a comment - I noticed after I submitted that comment that it doesn't happen unless the git-publisher is enabled (post-build action). As soon as it's enabled, it starts generating tags of the form "jenkins-$ {project} -$ {build_number} -SUCCESS"
          Hide
          feystorm Patrick Hemmer added a comment -

          Looks like it's from this: https://github.com/jenkinsci/git-plugin/blob/e384fbff87fec3473f7032760dfd0f4ec5285896/src/main/java/hudson/plugins/git/GitPublisher.java#L215
          The code does have a conditional gitSCM.getSkipTag, but I have no clue what controls that.

          Show
          feystorm Patrick Hemmer added a comment - Looks like it's from this: https://github.com/jenkinsci/git-plugin/blob/e384fbff87fec3473f7032760dfd0f4ec5285896/src/main/java/hudson/plugins/git/GitPublisher.java#L215 The code does have a conditional gitSCM.getSkipTag , but I have no clue what controls that.
          Hide
          owenmehegan owenmehegan added a comment -

          1. I think if you previously used a version of the git plugin which DID enable tags on builds by default, then simply upgrading to the version where tags are disabled by default would not change that setting in your existing builds. You would need to manually do that.
          2. In either case, I think the tags are only created in your local checkout of the repo. They would not be pushed to the remote repo unless you happened to do a 'git push' or 'git push --tags' as part of your build job, or used the git-publisher action as Patrick points out. In my case we create our own tags for builds, in certain cases, and push those. Each time we did that we would also end up with the superfluous Jenkins tags crapping up the remote repo. I think this is why not everyone saw this auto-tag behavior as such a big deal.

          Show
          owenmehegan owenmehegan added a comment - 1. I think if you previously used a version of the git plugin which DID enable tags on builds by default, then simply upgrading to the version where tags are disabled by default would not change that setting in your existing builds. You would need to manually do that. 2. In either case, I think the tags are only created in your local checkout of the repo. They would not be pushed to the remote repo unless you happened to do a 'git push' or 'git push --tags' as part of your build job, or used the git-publisher action as Patrick points out. In my case we create our own tags for builds, in certain cases, and push those. Each time we did that we would also end up with the superfluous Jenkins tags crapping up the remote repo. I think this is why not everyone saw this auto-tag behavior as such a big deal.
          Hide
          markewaite Mark Waite added a comment -

          Adding the Git Publisher step was the magic for me. Once that is added, then the jenkins-job_name-job_number-SUCCESS tag is written for each successful job.

          As far as I can tell, Owen Mehegan is correct that the tags are entirely local to the repository, unless you specifically choose to push the tag. Can you further describe the cause of your concern for those extra tags in the repository?

          Show
          markewaite Mark Waite added a comment - Adding the Git Publisher step was the magic for me. Once that is added, then the jenkins-job_name-job_number-SUCCESS tag is written for each successful job. As far as I can tell, Owen Mehegan is correct that the tags are entirely local to the repository, unless you specifically choose to push the tag. Can you further describe the cause of your concern for those extra tags in the repository?
          Hide
          feystorm Patrick Hemmer added a comment -

          The problem this causes is with things that use the tags. A good example would be git describe --tags. A build job might use this command to generate a version for the build. However with the jenkins tags getting added in, this breaks as the command returns the wrong tag.

          I've ended up just adding git tag d $(git tag --list 'jenkins*') to my build jobs. It's dirty, but it works.

          Show
          feystorm Patrick Hemmer added a comment - The problem this causes is with things that use the tags. A good example would be git describe --tags . A build job might use this command to generate a version for the build. However with the jenkins tags getting added in, this breaks as the command returns the wrong tag. I've ended up just adding git tag d $(git tag --list 'jenkins *') to my build jobs. It's dirty, but it works.

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              alskor Alexey Java
            • Votes:
              6 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: