When using Pipeline Multibranch with a Pipeline script that checkout the branch scm and also a different branch of the same repo later on, the next build changelog contains all commit history (bounded to a maximum).
Here is a sample scenario:
- Use a Jenkinsfile like the following (you may use the declarative default checkout or not):
- Create a Multibranch for this
- The first build shows no changelog (expected)
- The next builds (whether there is a change or not) shows the entire build history in the change log
While collecting some evidence, I noticed that the git whatchanged command that is launched to calculate the changelog of the main branch (the one from checkout scm) refers to a commit of the other branch that is checked out.
Looking through the code, I narrowed this down to the SpecificRevisionBuildChooser that just returns the last recorded git build data when asked for the previous build revision of a branch.
The GitSCM#computeChangeLog kind of assume that the revision returned by the chooser is valid if found in the repo.
In the scenario shown above, the last git build data is from a different branch. While it exists in the repo apparently, it is from a different branch. In the console output we see something like this where 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 is from the branch of the checkout scm and d185a06ad42d21210864bb1abddf60289dfc59de is from the checkout of the otherBranch from the last build. Not even in the history of branch of interest...:
A workaround might be to not rely on git / checkout step for the checkout of other branches. For example: