[JENKINS-38033] Make the changes list for a build job more accurate

[timja]

The list of changes for a build has several common scenarios where it is not correct.

1. When using one build job to handle multiple Git branches every time the job has to switch between branches, the list of changes "explodes" to show all differences between the branches.
2. When using build strategy that requires a fresh checkout/clone the list of changes are not reported at all
3. When you commit and build fails for "reasons", such as disk full or some service is down, when you re-run the job the new job does not show any changes

I believe this could be improved by doing something like the following:

• Store a "ref" and "revision" pair for last successful build. It should probably be configurable whether unstable builds are stored. "ref" would be something appropriate for the VCS such as a path in SVN or a ref in Git.
• If there is no stored ref/rev pair, then show the HEAD change in the list
• If there is a stored pair, then show all of the changes since that rev
• Of course update the stored pair at end of build if it is successful

A system like this could solve all of the problems mentioned and provide a more accurate picture of the relevant changes that contributed to the build.

---

Originally reported by markphip, imported from: Make the changes list for a build job more accurate

• status: Closed
• priority: Major
• resolution: Won't Fix
• resolved: 2017-06-16T15:27:42+00:00
• imported: 2022/01/10

[timja]

markewaite:

There is a system inside the git plugin and in other plugins which I believe stores the information you're describing. It is called BuildData and it tracks a number of different things about the build. It has also been a source of serious memory bloat and painful performance harm to Jenkins server startup, since all the BuildData for every job is read on startup. Two different attempts have been made to reduce the harm from BuildData. Both attempts failed.

I think the "change from one branch to another within the same job" use case is better handled by having jobs automatically created and destroyed as branches are created and destroyed. The multi-branch freestyle job plugin, the multi-branch pipeline plugin and the GitHub Organization Folders plugins all provide automatic job creation and deletion when branches are created and deleted. The change results are much easier to read when all the changes are for a single branch.

[timja]

jglick:

When using one build job to handle multiple Git branches

Switch to multibranch rather than using this antipattern.

When using build strategy that requires a fresh checkout/clone the list of changes are not reported at all

Should work if your SCM does not require workspace-based polling. If it does, it will need to be changed, ideally.

When you commit and build fails for "reasons", such as disk full or some service is down, when you re-run the job the new job does not show any changes

In freestyle perhaps. In Pipeline it should depend on whether it got as far as the checkout or not.