The Perforce plugin mishandles processing query for P4 changes during job
execution. From the console log, it appears that if I have a P4 CL description
pasted into a P4 CL, the parsing goes into the weeds and generates an error.
File names changed to protect the innocent, but this is the stderr log:

875082651 Executor #2 for master WARN perforce - File
Line: ... //depot/main/somefilepath/somefilename.java#7 integrate
875082651 Executor #2 for master INFO perforce - Executing: p4 describe -s
208013
875082714 Executor #2 for master WARN perforce - File
Line: //depot/dev/somebranch/someotherfilepath/yet-another-filename#4
875082714 Executor #2 for master ERROR perforce - Exception: No enum const
class com.tek42.perforce.model.Changelist$FileEntry$Action.
com.tek42.perforce.PerforceException: Failed to retrieve changelist.
at com.tek42.perforce.parse.ChangelistBuilder.build
(ChangelistBuilder.java:146)
at com.tek42.perforce.parse.Changes.getChangelist(Changes.java:35)
at com.tek42.perforce.parse.Changes.getChangelistsFromNumbers
(Changes.java:281)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:231)
at hudson.model.AbstractProject.checkout(AbstractProject.java:573)
at hudson.model.AbstractBuild$AbstractRunner.checkout
(AbstractBuild.java:251)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:225)
at hudson.model.Run.run(Run.java:756)
at hudson.model.Build.run(Build.java:85)
at hudson.model.ResourceController.execute(ResourceController.java:70)
at hudson.model.Executor.run(Executor.java:82)
Caused by: java.lang.IllegalArgumentException: No enum const class
com.tek42.perforce.model.Changelist$FileEntry$Action.
at java.lang.Enum.valueOf(Enum.java:196)
at com.tek42.perforce.model.Changelist$FileEntry$Action.valueOf
(Changelist.java:61)
at com.tek42.perforce.parse.ChangelistBuilder.build
(ChangelistBuilder.java:136)
... 10 more

The problem is that the CL associated with another change was cut-n-pasted into
P4 changelist 208013. This included the complete CL description, with
the "Affected Files:" section, where the //depot/dev/somebranch/... file was
referenced.

I confirmed this root cause by updated the offending CL to remove the
embedded "Affected Files:" section and it moved happily ahead.

The fix involves extracting only the TRUE 'Affected Files:' section from the
CL, rather than the red herring.

Please contact me if you need additional information.

Regards,
Mike