Summary

The plugin uses p4 changes -m20 //CLIENT/...@CL1,LAST_CL to fetch the changelog since the previous build.

But it uses p4 changes -l -m1 @CL to fetch the details of each change, without scoping it to the Perforce client/workspace. The @CL filter without a file pattern doesn't seem to always work properly and can return any recent CL from the Perforce server, even from different repositories.

Respective code paths – Checkout.getChangesFull() calls:

• To get the list, ClientHelper.listChanges() that adds the scope: jenkinsci/p4-plugin/...p4/client/ClientHelper.java#L1208-L1209
• To get individual changes, change.getChangeEntry() for a P4ChangeRef -> ConnectionHelper.getChangeSummary(id) that doesn't add the scope: jenkinsci/p4-plugin/...ConnectionHelper.java#L405-L410

Symptoms

We noticed the following on a recent build's Perforce sync:

...
(p4):cmd:... p4 changes -m20 //jenkins-[WORKSPACE-ID]___
p4 changes -m20 //jenkins-[WORKSPACE-ID]-0/...@3574547,3575421

Change 3575421 on 2021/02/09 by X@Y ...
Change 3575321 on 2021/02/09 by X@Y ...
Change 3574547 on 2021/02/08 by X@Y ...
(p4):stop:8
(p4):cmd:... p4 changes -l -m1 @3575421
p4 changes -l -m1 @3575421

Change 3575420 on 2021/02/09 by swarmadmin@swarm-2c02b25f-[snip] *pending* [snip CL description]
(p4):stop:9
(p4):cmd:... p4 user -o swarmadmin
p4 user -o swarmadmin

(p4):stop:10
(p4):cmd:... p4 describe -s -S 3575420
p4 describe -s -S 3575420

(p4):stop:11
(p4):cmd:... p4 fixes -c3575420
p4 fixes -c3575420

(p4):stop:12
(p4):cmd:... p4 changes -l -m1 @3575321
p4 changes -l -m1 @3575321

Change 3575321 on 2021/02/09 by X@Y ...
..

• p4-jenkins found CLs 3575421, 3575321 for the build changes (+ 3574547 from previous build/syncID)
• Fetching details for CL 3575421 found... CL 3575420????
• Fetching details for CL 3575321 found 3575321 details
• → CLs 3575420 and 3575321 are saved in the Jenkins build's "changes".

After testing the behaviour of p4 changes -l -m1 @X I'm surprised this works at all for most CLs (3575321 above), the command seems to always return the very latest CL on the entire Perforce server when I run it locally:

> p4 changes -l -m1 @3575321
Change 3578492 on 2021/02/16 by Y@Z...

We have configured our builds with email-ext to send notifications to "culprits", i.e. all CL authors that led to a build failure. As this relies on the changes recorded by p4-jenkins, the wrong changes can notify the wrong people.
Our case above ended up emailing our IT department (swarmadmin) as the owner of that Swarm change that was completely unrelated to the build.

(internal ref: stresstest#130)