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

Possible polling loop with SpecificRevisionBuildChooser created from Shared Library Modern SCM Git

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None
    • 4.7.1

      If we configure a Shared Library using Modern Git SCM with the trait "Discover branches" and the option "Include @Library changes in job recent changes" enabled. If we choose a *tag* as a "Default version" or if we "Allow default version to be overridden" and a user creates a pipeline like the following that uses a *tag*:

      @Library("shared-libs@1.0") _

      The pipeline works but finds a matching branch with the tag revision:

      Loading library shared-libs@1.0
Attempting to resolve 1.0 from remote references...
 > git --version # timeout=10
 > git --version # 'git version 2.28.0'
using GIT_ASKPASS to set credentials support-team-up
 > git ls-remote -h -- https://github.example.com/support-team/shared-librairies.git # timeout=10
Could not find 1.0 in remote references. Pulling heads to local for deep search...
 > git rev-parse --resolve-git-dir /tmp/je-1-home/caches/git-9390156b652cbc2296179d56e56ff5e4/.git # timeout=10
Setting origin to https://github.example.com/support-team/shared-librairies.git
 > git config remote.origin.url https://github.example.com/support-team/shared-librairies.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > git --version # timeout=10
 > git --version # 'git version 2.28.0'
 > git config --get remote.origin.url # timeout=10
using GIT_ASKPASS to set credentials support-team-up
 > git fetch --tags --force --progress -- origin +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git rev-parse 1.0^{commit} # timeout=10
 > git branch -a -v --no-abbrev --contains b671c5ed16715d2c38ff8d0b16f2007c97108383 # timeout=10
Selected match: master revision b671c5ed16715d2c38ff8d0b16f2007c97108383
Selected Git installation does not exist. Using Default
The recommended git tool is: NONE
using credential support-team-up
 > git rev-parse --resolve-git-dir /tmp/je-1-home/workspace/testSharedLibsPolling@libs/shared-libs/.git # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.example.com/support-team/shared-librairies.git # timeout=10
Fetching without tags
Fetching upstream changes from https://github.example.com/support-team/shared-librairies.git
 > git --version # timeout=10
 > git --version # 'git version 2.28.0'
using GIT_ASKPASS to set credentials support-team-up
 > git fetch --no-tags --force --progress -- https://github.example.com/support-team/shared-librairies.git +refs/heads/*:refs/remotes/origin/* # timeout=10
Checking out Revision b671c5ed16715d2c38ff8d0b16f2007c97108383 (master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b671c5ed16715d2c38ff8d0b16f2007c97108383 # timeout=10

      If polling is enabled and the revision is not the latest of the matching branch (here master) then polling will always find changes between the tag revision is always behind the matching branch of the SpecificRevisionBuildChooser.

      Started on 28/05/2021 10:14:00 AM
Using strategy: SpecificRevisionBuildChooser
[poll] Last Built Revision: Revision b671c5ed16715d2c38ff8d0b16f2007c97108383 (master)
Selected Git installation does not exist. Using Default
The recommended git tool is: NONE
using credential support-team-up
 > git --version # timeout=10
 > git --version # 'git version 2.28.0'
using GIT_ASKPASS to set credentials support-team-up
 > git ls-remote -h -- https://github.example.com/support-team/shared-librairies.git # timeout=10
Found 35 remote heads on https://github.example.com/support-team/shared-librairies.git
[poll] Latest remote head revision on refs/heads/master is: aba9e45864e1ca560a39fa911f2d51b529c9e4bd
Done. Took 2.5 sec
Changes found

      Thoughts

      Even though "Discover Tags" trait, the tag can be resolved to a matching branch and that has consequences on the polling. I am not sure if this is a bug (either the way polling behave with SpecificRevisionBuildChooser or the fact that a tag revision can be resolved without Tag discovery enabled) or simply a misconfiguration problem. Apparently for polling, the build chooser only matters if there is a workspace and polling requires it: https://github.com/jenkinsci/git-plugin/blob/git-4.7.1/src/main/java/hudson/plugins/git/GitSCM.java#L803-L804.

      Note: This is not reproducible with GitHub SCM. Strangely enough, even if "Discover Tags" is not added, it can resolve also it and polling does not find changes, because of the narrow refspec applied I suppose:

      Started on 28/05/2021 10:56:00 AM
Using strategy: SpecificRevisionBuildChooser
[poll] Last Built Revision: Revision b6ef379ab5aff222893f8c585102a08befadc5f5 (1.0)
The recommended git tool is: NONE
using credential support-team-up
 > git --version # timeout=10
 > git --version # 'git version 2.28.0'
using GIT_ASKPASS to set credentials support-team-up
 > git ls-remote -h -- https://github.example.com/support-team/shared-librairies.git # timeout=10
Found 35 remote heads on https://github.example.com/support-team/shared-librairies.git
Ignoring refs/heads/master as it doesn't match any of the configured refspecs
No changes

      How to Reproduce

      In a Git repository:

      • create a test branch "test/specificRevisionBuildChooser" git checkout -B test/specificRevisionBuildChooser
      • from that branch create a tag git tag 1.0 && git push origin 1.0
      • make a change to the branch "test/specificRevisionBuildChooser" and push it

      You have:

      • tag 1.0 for with the HEAD has matching revision in test/specificRevisionBuildChooser
      • branch test/specificRevisionBuildChooser for which the HEAD is 1 commit ahead of tag 1.0's HEAD.

      Configure a Shared Library:

      • Name "shared-libs"
      • Use Modern SCM > Git
      • Enable "Include @Library changes in job recent changes" and "Allow default version to be overridden"
      • Add the trait "Discover Branches"
      • Add the trait "Filter by name (with wildcards)" and set "Include" to test/specificRevisionBuildChooser

      Create a pipeline like the following:

      properties([pipelineTriggers([pollSCM('H/2 * * * *')])])
@Library("shared-libs@1.0") _
echo "OK"

      Build the pipeline. It should find the revision from the matching branch test/specificRevisionBuildChooser and then every poll run will trigger a build.

      Workaround / Solution

      • One workaround is to disable "Allow default version to be overridden".
      • The solution is to add the discovery trait "Discover Tags" to make sure that the SpecificRevisionBuildChooser points to the the *tag* and not a matching branch.

      *Either of those will take effect after jobs have been rebuilt at least once.*

            markewaite Mark Waite
            allan_burdajewicz Allan BURDAJEWICZ
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: