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

Drop --first-parent from rev count

    Details

    • Similar Issues:
    • Epic Link:

      Description

      There seems to be a problem with the policy of only traversing the first merge parent when determining the rev count portion of an incremental version number: it is not guaranteed that this count will be higher than the count of an ancestor commit. While the count is always higher “within a branch”, this does not necessarily hold when merging one branch into another: an old derivative branch may have a shorter line of development while pulling in a long list of changes from an upstream branch. In turn this means that incrementals:update sometimes selects a commit which looks newer than the current dependency version, and is an ancestor of the selected branch head, and yet which is not the maximal such commit topologically.

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          For example, in a dep on workflow-job-plugin,

          Searching for updates to org.jenkins-ci.plugins.workflow:workflow-job:2.22-rc300.4c8c8ab531e3 within jglick:logs-JENKINS-38381
          Found 79 candidates from https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/workflow/workflow-job/2.22-rc344.2563730618be/ down to https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/workflow/workflow-job/0.1-beta-1/
          Considering https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/workflow/workflow-job/2.22-rc344.2563730618be/
          Mapped to: https://github.com/jenkinsci/workflow-job-plugin/commit/2563730618be282ec4c183338c9c8dcf5f5f1c93
          Seems to be within jglick:logs-JENKINS-38381, so accepting
          Can update dependency org.jenkins-ci.plugins.workflow:workflow-job:jar:2.22-rc300.4c8c8ab531e3 to 2.22-rc344.2563730618be
          

          Even though 344 > 300, this is wrong since

          workflow-job-plugin$ git merge-base 2563730618be 4c8c8ab531e3
          2563730618be282ec4c183338c9c8dcf5f5f1c93
          

          Dropping --first-parent would have fixed the problem:

          workflow-job-plugin$ for c in 2563730618be 4c8c8ab531e3; do echo $c; git rev-list --count --first-parent $c; git rev-list --count $c; done
          2563730618be
          344
          739
          4c8c8ab531e3
          300
          780
          

          Assuming performance is acceptable, it ought to be compatible to change incrementals-tools to use the new strategy, since the change will only apply to commits which pick up the new version of the tool, and the count will be no less than what it would have been otherwise.

          Show
          jglick Jesse Glick added a comment - For example, in a dep on workflow-job-plugin , Searching for updates to org.jenkins-ci.plugins.workflow:workflow-job:2.22-rc300.4c8c8ab531e3 within jglick:logs-JENKINS-38381 Found 79 candidates from https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/workflow/workflow-job/2.22-rc344.2563730618be/ down to https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/workflow/workflow-job/0.1-beta-1/ Considering https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/workflow/workflow-job/2.22-rc344.2563730618be/ Mapped to: https://github.com/jenkinsci/workflow-job-plugin/commit/2563730618be282ec4c183338c9c8dcf5f5f1c93 Seems to be within jglick:logs-JENKINS-38381, so accepting Can update dependency org.jenkins-ci.plugins.workflow:workflow-job:jar:2.22-rc300.4c8c8ab531e3 to 2.22-rc344.2563730618be Even though 344 > 300, this is wrong since workflow-job-plugin$ git merge-base 2563730618be 4c8c8ab531e3 2563730618be282ec4c183338c9c8dcf5f5f1c93 Dropping --first-parent would have fixed the problem: workflow-job-plugin$ for c in 2563730618be 4c8c8ab531e3; do echo $c; git rev-list --count --first-parent $c; git rev-list --count $c; done 2563730618be 344 739 4c8c8ab531e3 300 780 Assuming performance is acceptable, it ought to be compatible to change incrementals-tools to use the new strategy, since the change will only apply to commits which pick up the new version of the tool, and the count will be no less than what it would have been otherwise.
          Hide
          jglick Jesse Glick added a comment -

          Tricky to make sure plugin authors remember to update git-changelist-maven-extension. Maybe plugin-pom can somehow report an Enforcer error if the version in use is older than some threshold.

          Show
          jglick Jesse Glick added a comment - Tricky to make sure plugin authors remember to update git-changelist-maven-extension . Maybe plugin-pom can somehow report an Enforcer error if the version in use is older than some threshold.

            People

            • Assignee:
              jglick Jesse Glick
              Reporter:
              jglick Jesse Glick
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: