-
Bug
-
Resolution: Unresolved
-
Minor
-
Jenkins 2.319.3
Git Plugin 4.10.3
Git Client Plugin 3.11.0
GitHub 1.34.2
We are trying to avoid build steps as much as possible, for example skipping some of then when a build was triggered by a upstream project but did not have any changes on its own or a commit message contained a specified string (aka [skip ci]).
Therefor we heavily rely on the currentBuild.changeSets.
Unfortunatly we recently discovered that builds are triggered when a force push is used (which is good) to a repository, but the changes are empty (thats not expected). This can also be seen in the corresponding UI.
There might be other constellations where it does not work but this is one we could reproduce.
This is a known limitation of the changeset computation. It assumes that the base version of the changeset exists.
A force push frequently deletes the base version of the changeset. Selecting a new base version of the changeset is a non-trivial exercise that would need some form of heuristic to guide it. For example, after a force push, should the changeset use the version from a build that is older than the previous build? After a force push, should the changeset show only a single commit? If so, then what about users that force push a set of changes that contain multiple commits? After a force push, should the changeset show the changes since the most recent commit that has more than one successors? Each of the rules that I can envision for selecting the comparison base for a force push will have users that see the choice as flawed.