I am getting similar behavior except with Subversion.

When I look at the details of the build it tells me that it was started by an SCM change but that there are no changes:

-------------------
Revision: <some number>
No changes.

Started by an SCM change
---------------------

If I catch the Subversion polling log (from the link on the project page) in time it will tell me something like the following:

--------------------------------------
Started on Mar 11, 2010 6:27:44 PM
Workspace doesn't contain svn://<svn path here>/trunk. Need a new build.
Done. Took 62 ms
Changes found
---------------------------------------

I am not sure if this issue is related or not since it is a different SCM system but I thought it too coincidental.

The subversion problem is most likely unrelated.

rshelley, could you please post the contents of the Polling Log from the project page after this happens?

Also, what version of the perforce plugin are you using?

(I have abridged some paths for brevity)

Started on Mar 11, 2010 5:41:27 PM
Looking for changes...
Using master perforce client: hudson-tp1.02
[workspace] $ "C:\\Program Files\\Perforce\\p4.exe" workspace -o hudson-tp1.02
[workspace] $ "C:\\Program Files\\Perforce\\p4.exe" login -p
[workspace] $ "C:\\Program Files\\Perforce\\p4.exe" -P 
17B248590192249F0693BD51748B35EB workspace -o hudson-tp1.02
Changing P4 Client Root to: C:\Documents and Settings\LocalService\.hudson\jobs\mod-cacheutility\workspace\
Changing P4 Client View from:
  //p4/.../travel/... //hudson-tp1.02/travel/...
Changing P4 Client View to: 
  //p4/.../cacheutility/... //hudson-tp1.02/...
Last sync'd change was 654807
[workspace] $ "C:\\Program Files\\Perforce\\p4.exe" -P 17B248590192249F0693BD51748B35EB changes -m 2 //hudson-tp1.02/...
Latest submitted change selected by workspace is 654813
Triggering a build.
Done. Took 1.8 sec
Changes found

Note that the changelist it's referencing, 654813, contains files not in the view of the Perforce workspace "/cacheutility/", so that changelist shouldn't have been retrieved. That changelist actually contained files that were (maybe coincidentally) in the "/travel/" view. The last changelist that has changes that would be visible to this view would be 654807.

Now, something that stands out is the line "Latest submitted change selected by workspace is...". I actually re-use my Hudson Perforce workspace for each of my builds (travel, cacheutility, etc). Each of those builds has a different Perforce view that I allow the Perforce plugin to change, and those views don't overlap. So when the build ran for "/travel/" the last changelist was 654813, but when the view changed to "/cacheutility/", the last changelist for the workspace is still associated with the prior view for "/travel/", so it will always be different, always triggering a build.

I have a feeling the polling function isn't actually saving the new workspace before checking for changes. Client specs don't normally change that frequently, so I've never noticed it before. I'll take a look and try to get a fix in before the next release tomorrow.

Reusing a client workspace between jobs is definitely something you shouldn't do, because that could easily result in an inconsistent sync. Though in your case it only works because your paths don't overlap. I would highly recommend using a different client workspace for each build. If two of those builds happen to run at the same time, or even if a build runs while a poll is running for another job, you can get some seriously messed up results...

Ah, that would make some sense then. It would almost make more sense, in that case, to prohibit the re-use of a workspace between jobs that have different views. Any way, I'll add new views for each job and that should fix it. Thanks!

Code changed in hudson
User: : rpetti
Path:
trunk/hudson/plugins/perforce/src/main/webapp/help/p4Client.html
http://jenkins-ci.org/commit/28528
Log:
JENKINS-5915 modifying documentation to make it more clear that reusing a client workspace for multiple jobs is a bad idea.

Code changed in hudson
User: : rpetti
Path:
trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java
http://jenkins-ci.org/commit/28527
Log:
[FIXED JENKINS-5915] let polling save the new client workspace if it's changed, so it can check for new changes against the proper view spec.

Thanks for looking into this promptly. Working much better with separate workspaces.