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

Project building from tag builds at each polling interval

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
    • Environment:
      Jenkins 1.565
      Git Client Plugin 1.8.1
      Git Plugin 2.2.1
    • Similar Issues:

      Description

      I have a job I changed to build from a tag. However, I'd left the polling enabled. I noticed that the job built every time that it polled. The polling log shows:

      Started on Jun 3, 2014 7:20:00 PM
      Using strategy: Default
      [poll] Last Built Revision: Revision aacfd8d1828633ccfb7ced255e795a29e31d6228 (mytag)
      > git ls-remote -h git@hostname:my/project mytag
      Done. Took 0.39 sec
      Changes found

      I noticed that the ls-remote command is being passed "-h", which I believe is causing the issue. The -h would exclude tags. Thus:

      $ git ls-remote -h git@hostname:my/project mytag

      Yields no results, but removing the "-h":

      $ git ls-remote git@hostname:my/project mytag
      aacfd8d1828633ccfb7ced255e795a29e31d6228 refs/tags/mytag

        Attachments

          Activity

          Hide
          blt04 Brandon Turner added a comment -

          FYI: This should fix this: https://github.com/jenkinsci/git-client-plugin/pull/135 It hasn't been merged yet, but that PR does remove the "-h".

          Show
          blt04 Brandon Turner added a comment - FYI: This should fix this: https://github.com/jenkinsci/git-client-plugin/pull/135 It hasn't been merged yet, but that PR does remove the "-h".
          Hide
          markewaite Mark Waite added a comment -

          This is still repeatable, even with the change which removes the "-h" from the git ls-remote command line.

          In my example, I created a job to build the git-client-plugin with the tag "refs/tags/git-client-1.10.0".

          The first poll correctly detected that no build had been done, and the git ls-remote command reported the SHA1 of the tag, "2b8dd77821fc95a73b309b440e745b3e146c1e74".

          The second and later polls continue to report the SHA1 of the tag, even though the repository had checked out the SHA1 of the commit to which the tag is pointing. That commit is "1fb23708d6b639c22383c8073d6e75051b2a63aa". Since the SHA1 returned by git ls-remote and the SHA1 of the local repository are different, the plugin assumes another build is required to make them the same. Since they can never be the same (because the ls-remote is requesting the SHA1 of the tag, not the SHA1 of the commit identified by the tag), the builds will run at every polling interval.

          Show
          markewaite Mark Waite added a comment - This is still repeatable, even with the change which removes the "-h" from the git ls-remote command line. In my example, I created a job to build the git-client-plugin with the tag "refs/tags/git-client-1.10.0". The first poll correctly detected that no build had been done, and the git ls-remote command reported the SHA1 of the tag, "2b8dd77821fc95a73b309b440e745b3e146c1e74". The second and later polls continue to report the SHA1 of the tag, even though the repository had checked out the SHA1 of the commit to which the tag is pointing. That commit is "1fb23708d6b639c22383c8073d6e75051b2a63aa". Since the SHA1 returned by git ls-remote and the SHA1 of the local repository are different, the plugin assumes another build is required to make them the same. Since they can never be the same (because the ls-remote is requesting the SHA1 of the tag, not the SHA1 of the commit identified by the tag), the builds will run at every polling interval.
          Hide
          drwille Daniel Wille added a comment -

          I still see Jenkins using the "-h" in polling. I'm using git-client 1.10.1 and git 2.2.5 at the moment. It does appear to strip the "-h" when I prefix with refs/tags. Is it intentional that the "-h" is only removed there and not globally?

          That aside, you're right about that tag issue. I'd initially only considered lightweight (i.e. not annotated) tags, which don't have their own object.

          Adding a suffix of "~0" or "^0" when using a tag will de-reference the tag and get the commit it refers to for many git operations, but that doesn't appear to work with "git ls-remote".

          Show
          drwille Daniel Wille added a comment - I still see Jenkins using the "-h" in polling. I'm using git-client 1.10.1 and git 2.2.5 at the moment. It does appear to strip the "-h" when I prefix with refs/tags. Is it intentional that the "-h" is only removed there and not globally? That aside, you're right about that tag issue. I'd initially only considered lightweight (i.e. not annotated) tags, which don't have their own object. Adding a suffix of "~0" or "^0" when using a tag will de-reference the tag and get the commit it refers to for many git operations, but that doesn't appear to work with "git ls-remote".
          Hide
          markewaite Mark Waite added a comment -

          It is intentional that the "-h" is only dropped when the "refs/tags/tag_name" syntax is used, since that syntax was a new addition and we were not confident we could predict all the side effects if we removed the "-h" from the general case.

          There is a suffix we can add which does resolve with ls-remote. It is

          git ls-remote tag_name^{}
          

          I haven't yet looked to see if that is safe for both annotated and lightweight tags. If not, then it might require two calls to "git ls-remote" in the refs/tags case, once for annotated tags and once for lightweight tags.

          Show
          markewaite Mark Waite added a comment - It is intentional that the "-h" is only dropped when the "refs/tags/tag_name" syntax is used, since that syntax was a new addition and we were not confident we could predict all the side effects if we removed the "-h" from the general case. There is a suffix we can add which does resolve with ls-remote. It is git ls-remote tag_name^{} I haven't yet looked to see if that is safe for both annotated and lightweight tags. If not, then it might require two calls to "git ls-remote" in the refs/tags case, once for annotated tags and once for lightweight tags.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
          src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java
          http://jenkins-ci.org/commit/git-client-plugin/4362cf66b19519a558984d33f7e4272131087b6a
          Log:
          [Fix JENKINS-23299] tag based builds run at every poll

          When a build is defined to use a tag, the "check for changes" uses
          ls-remote to compare the SHA1 of the remote tag to the SHA1 of the HEAD
          of the working directory. The tag SHA1 is not always the same as the
          commit SHA1 (annotated tags), so when that happens, the ls-remote based
          "check for changes" can never be satisfied.

          This change adapts the tag specific check for changes to use a syntax
          which returns the SHA1 of the commit referenced by the tag rather than
          the SHA1 of the tag.

          JGit always returns the SHA1 of the commit referenced by a tag (a
          "peeled" object), while CliGit returns a "peeled" object for tags only
          if the refs/tags/tag_name syntax is used.

          That difference is maintained for behavioral compatibility for users
          of CliGit. Cases where returning the SHA1 of the tag would be better
          than returning the SHA1 of the commit referenced by the tag seem rare,
          but better to retain CliGit compatibility than risk surprising users in
          some as yet undetected use case.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java http://jenkins-ci.org/commit/git-client-plugin/4362cf66b19519a558984d33f7e4272131087b6a Log: [Fix JENKINS-23299] tag based builds run at every poll When a build is defined to use a tag, the "check for changes" uses ls-remote to compare the SHA1 of the remote tag to the SHA1 of the HEAD of the working directory. The tag SHA1 is not always the same as the commit SHA1 (annotated tags), so when that happens, the ls-remote based "check for changes" can never be satisfied. This change adapts the tag specific check for changes to use a syntax which returns the SHA1 of the commit referenced by the tag rather than the SHA1 of the tag. JGit always returns the SHA1 of the commit referenced by a tag (a "peeled" object), while CliGit returns a "peeled" object for tags only if the refs/tags/tag_name syntax is used. That difference is maintained for behavioral compatibility for users of CliGit. Cases where returning the SHA1 of the tag would be better than returning the SHA1 of the commit referenced by the tag seem rare, but better to retain CliGit compatibility than risk surprising users in some as yet undetected use case.
          Hide
          markewaite Mark Waite added a comment -

          Fixed in git-client-plugin 1.10.2, released 12 Sep 2014

          Show
          markewaite Mark Waite added a comment - Fixed in git-client-plugin 1.10.2, released 12 Sep 2014
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          pom.xml
          http://jenkins-ci.org/commit/git-plugin/4682d5ede81be35da32026c5a1e2124d59c230e3
          Log:
          Revert "Depend on git-client 1.10.2" until test failure fixed

          This reverts commit 87beb7d0270c3058c90fd178b0aa96049ad6a900 until
          the automated test which fails in the code can be fixed. The test is
          specifically noted that it is an area of bugs in the prior client plugin,
          and the fix of JENKINS-23299 in git client plugin 1.10.2 has improved
          the behavior, but the test needs to be updated to show the new behavior
          (and have its TODO comment removed).

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: pom.xml http://jenkins-ci.org/commit/git-plugin/4682d5ede81be35da32026c5a1e2124d59c230e3 Log: Revert "Depend on git-client 1.10.2" until test failure fixed This reverts commit 87beb7d0270c3058c90fd178b0aa96049ad6a900 until the automated test which fails in the code can be fixed. The test is specifically noted that it is an area of bugs in the prior client plugin, and the fix of JENKINS-23299 in git client plugin 1.10.2 has improved the behavior, but the test needs to be updated to show the new behavior (and have its TODO comment removed).
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          pom.xml
          http://jenkins-ci.org/commit/git-plugin/8add48556e33f1bbb1595402086644863e0bbb63
          Log:
          Revert "Update git-client dependency to 1.10.2"

          This reverts prior commit until the automated test which fails in the
          code can be fixed. The test is specifically noted that it is an area
          of bugs in the prior client plugin. The fix of JENKINS-23299 in git
          client plugin 1.10.2 has improved the behavior, but the test needs to
          be updated to show the new behavior (and have its TODO comment removed).

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: pom.xml http://jenkins-ci.org/commit/git-plugin/8add48556e33f1bbb1595402086644863e0bbb63 Log: Revert "Update git-client dependency to 1.10.2" This reverts prior commit until the automated test which fails in the code can be fixed. The test is specifically noted that it is an area of bugs in the prior client plugin. The fix of JENKINS-23299 in git client plugin 1.10.2 has improved the behavior, but the test needs to be updated to show the new behavior (and have its TODO comment removed).
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          pom.xml
          src/test/java/hudson/plugins/git/CliGitSCMTriggerRemotePollTest.java
          http://jenkins-ci.org/commit/git-plugin/f654185b384a67b4e107f86d52b1ff2797c616d0
          Log:
          Adapt tests for JENKINS-23299 fix and git-client-plugin 1.10.2

          Intentionally skip one test, enable another

          Depend on git-client-plugin 1.10.2

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: pom.xml src/test/java/hudson/plugins/git/CliGitSCMTriggerRemotePollTest.java http://jenkins-ci.org/commit/git-plugin/f654185b384a67b4e107f86d52b1ff2797c616d0 Log: Adapt tests for JENKINS-23299 fix and git-client-plugin 1.10.2 Intentionally skip one test, enable another Depend on git-client-plugin 1.10.2
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          pom.xml
          src/test/java/hudson/plugins/git/CliGitSCMTriggerRemotePollTest.java
          http://jenkins-ci.org/commit/git-plugin/12351a2ef8dc726144ae5e6234f0e240fc4a5977
          Log:
          Adapt tests for JENKINS-23299 fix and git-client-plugin 1.10.2

          Intentionally skip one test, enable another

          Depend on git-client-plugin 1.10.2

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: pom.xml src/test/java/hudson/plugins/git/CliGitSCMTriggerRemotePollTest.java http://jenkins-ci.org/commit/git-plugin/12351a2ef8dc726144ae5e6234f0e240fc4a5977 Log: Adapt tests for JENKINS-23299 fix and git-client-plugin 1.10.2 Intentionally skip one test, enable another Depend on git-client-plugin 1.10.2
          Hide
          progman Alexey Ostrovsky added a comment -

          It appears not working.
          I have Jenkins - 2.27
          Git Client Plugin - 2.0.0
          Git Plugin - 3.0.0

          Project configured to build from "refs/tags/ci-qa"
          But polling is still running with '-h'.
          As result build is not initiated when revision of tag is changed.

          Show
          progman Alexey Ostrovsky added a comment - It appears not working. I have Jenkins - 2.27 Git Client Plugin - 2.0.0 Git Plugin - 3.0.0 Project configured to build from "refs/tags/ci-qa" But polling is still running with '-h'. As result build is not initiated when revision of tag is changed.
          Hide
          peterjones Peter Jones added a comment -

          +1
          I have same request and am hitting same limitation where I cannot trigger a build just from a tag change (non-annotated tag).

          Will the use of annotated tags get around this limitation ?

          Show
          peterjones Peter Jones added a comment - +1 I have same request and am hitting same limitation where I cannot trigger a build just from a tag change (non-annotated tag). Will the use of annotated tags get around this limitation ?
          Hide
          progman Alexey Ostrovsky added a comment -

          Are there any plans to fix that small but annoying bug?

          Show
          progman Alexey Ostrovsky added a comment - Are there any plans to fix that small but annoying bug?
          Hide
          markewaite Mark Waite added a comment -

          Alexey Ostrovsky No plans to fix this bug at this time. You're welcome to submit a pull request with automated tests which show the problem, and with a fix for the problem.

          Show
          markewaite Mark Waite added a comment - Alexey Ostrovsky No plans to fix this bug at this time. You're welcome to submit a pull request with automated tests which show the problem, and with a fix for the problem.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            drwille Daniel Wille
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Dates

              Created:
              Updated: