It already uses 'p4 changes -m 1 -s'. 'p4 counter change' is only used when looking for the actual latest change in the workspace. Here's an example from one of my own build logs:

[workspace] $ p4 counter change
[workspace] $ p4 -s changes -s submitted //installer/...@260018,@260111
[workspace] $ p4 describe -s 260103
...
Sync'ing workspace to changelist 260103.
[workspace] $ p4 -s sync //installer/...@260103

'p4 counter change' returns 260111, but as you can see, it's using the last changeset that was submitted in the view for syncing.

In the cases where you've seen different behavior, were there any changes made at all? I suspect it may be falling back onto the value provided by the counter when there are no changes available in the view, which is of course incorrect behavior.

Hi Rob,

Thank you for the quick response.

Your suspicion about the fallback is correct. Please consider these two situations:

1. In the case that prompted this ticket yesterday, there was a build that failed due to a file-locking issue. Our release administrator fixed the problem and pressed Build Now to restart the build. "p4 counter change" reported 24075, but no new submitted changelists were seen, so 24075 was picked as the official changelist number for the build. Ten minutes later, developer Kevin checked in changelist 24075. You see, it was pending before, and now it is submitted. Since the perforce plugin thinks it already built 24075, it never finds Kevin's checkin.
    
2. Even when submitted changelists are found, there is still a very subtle race condition here. If I may extend your example, say you had two view mappings: //installer/one/... and //installer/two/.... Now let's say changelist 260201 is pending on a file in //installer/one, and changelist 260202 is pending on a file in //installer/two. A build starts. "p4 counter change" says 260202. "p4 changes -s submitted //installer/one/...@260104,@260202" reports nothing. Then before the next call to "p4 changes" both changelists are checked in, and they are not renumbered. Now your "p4 changes -s submitted //installer/two/...@260104,@260202" finds changelist 260202. The build will contain both changes, yet the Jenkins build log only shows 260202. It missed the details of 260201 because of the race condition.

Bottom line is, "p4 counter change" is completely useless because it contains pending changelists that may or may not become submitted changelists. If you use "p4 changelists -m 1 -s submitted" (with no path!) in place of "p4 counter change" I believe these problems go away. You will get the latest submitted changelist number, and you are guaranteed to never have any new changelist submitted with a lower number.

I look forward to your thoughts on this.

The API doesn't currently support fetching changelists without specifying a path, so I was going to use "p4 changelists -m 1 -s submitted //..." instead. Does that sound good?

Interesting, the API must have changed somewhere along the way. (It is accepted by my Perforce setup.)

Anyway, yes, using //... sounds the same to me.

Thank you again!
--jsf

We're using the tek42 perforce api. The raw command itself still works, but there's currently no way to run it using the api.

I'll check in the fix after I've tested it a bit.

Code changed in jenkins
User: Rob Petti
Path:
src/main/java/hudson/plugins/perforce/PerforceSCM.java
http://jenkins-ci.org/commit/perforce-plugin/33720a12967b605ca3ebdcf39e735b17b642a174
Log:
JENKINS-13879 use the latest submitted depot change instead of counter when there are no changes to record

Released in 1.3.15.

I tried to use multiple SCM plugin to access to two different perforce servers in one jenkins job, wrote script code in powershell. Every time I build my job, it will automatically sync the work space, since my job contains two perforce clients, it need to sync from two servers. But the changeset number is always the first server's, so when I came to the second server, there will be an issue, the second server has a much larger change set, it will take a long time to describe the change because the changeset number is from the first server, at last I met the OutOfMemory error:

Building in workspace C:\jenkins\jobs\VCOPS_PLATFORM_AUTOTEST\workspace
Using master perforce client: VCOPSPLAT_STATS_SANDBOX
[workspace] $ C:\perforce-r10.2\p4.exe workspace -o VCOPSPLAT_STATS_SANDBOX

Last build changeset: 129940

[workspace] $ C:\perforce-r10.2\p4.exe changes -s submitted -m 1 //...
[workspace] $ C:\perforce-r10.2\p4.exe -s changes -s submitted //VCOPSPLAT_STATS_SANDBOX/...@129941,@129982
Sync'ing workspace to changelist 129982.
[workspace] $ C:\perforce-r10.2\p4.exe -s sync //VCOPSPLAT_STATS_SANDBOX/...@129982
Sync complete, took 364 ms
Using master perforce client: VCOPSPLAT_CLOUDVM_SANDBOX
[workspace] $ C:\perforce-r10.2\p4.exe workspace -o VCOPSPLAT_CLOUDVM_SANDBOX

Last build changeset: 129940

[workspace] $ C:\perforce-r10.2\p4.exe changes -s submitted -m 1 //...
[workspace] $ C:\perforce-r10.2\p4.exe -s changes -s submitted //VCOPSPLAT_CLOUDVM_SANDBOX/...@129941,@1934948
[workspace] $ C:\perforce-r10.2\p4.exe describe -s 1934844
[workspace] $ C:\perforce-r10.2\p4.exe -G where //...
[workspace] $ C:\perforce-r10.2\p4.exe describe -s 1934765
...

Is this due to perforce plugin or multiple SCM plugin?