Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Won't Fix
-
Component/s: git-client-plugin, git-plugin
-
Labels:None
-
Similar Issues:
Description
We use github-branch-source-plugin to detect changes.
Getting remote branch master... [Tue Nov 05 11:54:53 EST 2019] Received Push event to branch master in repository org/repo UPDATED event from 192.30.252.91 ⇒ https://jenkins/github-webhook/ with timestamp Tue Nov 05 11:54:48 EST 2019 11:54:53 Connecting to https://api.github.com using user@example.com/****** (User account for GitHub) Checking branch master Getting remote pull requests from branch master... ‘Jenkinsfile’ found Met criteria Changes detected: master (OLD-SHA → NEXT-SHA)
This is what triggered the build.
I checked github and confirmed, this is a single commit.
Actual result: Both classic and blueocean show 1024 changes listed for the build instead of the expected single commit (NEXT-SHA).
Attachments
Activity
The MAX_CHANGELOG value in the plugin is used to limit the maximum number of changes which might be attributed to a single commit. Default value is 1024. Since computeChangeLog takes BuildData previousBuildData as an argument, I assume that the 4.0.0-rc plugin version was not recording BuildData, so the 4.0.0 plugin version attempted to report the entire history as a change in that build. The 1024 upper bound prevented it assigning the entire repository history to that build.
I don't plan to attempt any fix to this bug. The git plugin 4.0.0-rc was a mistaken release that was blacklisted within two weeks of its release.
Please provide more information so that others can duplicate the problem. I've not seen such a problem.
The 4.0.0-rc version of the git plugin removed BuildData tracking from inside the plugin and replaced it with another class. That change introduced too many incompatibilities, so it was reverted for 4.0.0-beta10 and later. BuildData handling in git plugin 4.0.0 is different than in git plugin 4.0.0-rc but is the same as BuildData handling in git plugin 3.x. The return to 3.x behavior was crucial to maintain compatibility with other plugins that depend on BuildData assigned by the git plugin.