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
We noticed the following on a recent build's Perforce sync:
- 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:
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)