I have the folowing setup in Jenkins

Build job A --> Build job B

Build job A is triggered via Webhook after every commit in the associated Git repo, whereas the build job B is triggered through the "Jenkins Parameterized Trigger plugin".

Both build jobs are configured to use Git for SCM. In this way, each build job shows a list of changes compared to the previous build (a list of commits which were added to the Git repository between the previous build and the current build; e.g. Build B -> Build B + 1 can have one or more commits as change).

Furthermore I am using the "Jenkins Parameterized Trigger plugin" with "Pass-through Git Commit that was built" option. In this way build job B should be triggered for the same commit as build job A, even if a new commit was pushed after starting build job A but before build job B.

All build jobs are configured to run concurrently. Every run of those build jobs is performed on the same individual workspace one one Jenkins node like this:

======================================================================
 
Initial commit aaaaa happens:
Run #1 = Workspace #1: Build job A_1 --> Build job B_1    (on node N1)
 
New commit bbbbb happens:
Run #2 = Workspace #2: Build job A_2 --> Build job B_2    (on node N1)
 
New commit ccccc happens:
Run #3 = Workspace #3: Build job A_3 --> Build job B_3    (on node N2)
 
======================================================================

At my workplace we have a lot of commits each day. So our team decided to dynamically spin up Jenkins nodes based on the load. This means that build run #3 in the picture above can be performed on a nearly empty node N2 with a lot of available resources, while run #1 and #2 are running on the same node N1 with less resources. Hence, build run #3 goes a lot faster than #1 and #2!

Here comes the issue now:

When build job A_3 is started on the new node N2, this build job is finished before build job A_2 is done. Now, build job B_3 is triggered for commit ccccc. Since build job B_2 is not started, Jenkins finds that the changes in B_3 are "bbbbb" and "ccccc" (compared to the previous B_1). So far so good.

Later, when build job B_2 is started, this build job tells me that there are no changes at all! And I think this is wrong, or at least can lead to confusion.

In a timely manner this looks like the following:
Time goes on from top to bottom

 | ======================================================================
\|/  Initial commit aaaaa happens:
 |   Run #1 = Workspace #1: Build job A_1 -\
\|/                                         \
 |   New commit bbbbb happens:               \->   Build job B_1 (node N1, containing aaaaa)
 |   Run #2 = Workspace #2: Build job A_2 -\
\|/                                         \
 |   New commit ccccc happens:               \
\|/  Run #3 = Workspace #3: Build job A_3 --\ \
 |                                           \-\--> Build job B_3 (node N2, containing aaaaa, bbbbb and ccccc, changes: bbbbb and ccccc)
\|/                                             \-> Build job B_2 (node N1, containing aaaaa and bbbbb, **** no changes shown! ****)
======================================================================

While I understand that "bbbbb" and "ccccc" are shown as a difference in build job B_3 (compared to B_1), I do not understand why no changes are visible in B_2. Since it was triggered after B_3, it should show the difference between build Job B_2 and B_3, which is everything BUT ccccc!

Having said that I think we have an issue when Jenkins runs build jobs when using the "Jenkins Parameterized Trigger plugin" together with the "Pass-through Git Commit that was built" option. In this case, it can happen that no code change can be found compared to the previous build, although there is one.

A possible fix could be to change the way how the changes are then calculated in build job B. Instead of showing just additional changes by NEW commits, we have to keep in mind that through this timing issue (see my second sketch above) also LESS commits than in the previous build can occur.

Can anybody confirm that behavior? Is this a bug? Or am I understanding something wrong?