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

Drop --first-parent from rev count

    XMLWordPrintable

Details

    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

          Ascending order - Click to sort in descending order
          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.

          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.
          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.

          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

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

            Dates

              Created:
              Updated:
              Resolved: