Ah yes, I see. Passing changesets that way would probably be OK. I should try.

I thought the 'p4 counter' solution might be able to provide changelogs. The job would know the value of the counter (same as changelist number) for every build and should be able to find all changes between those. Precisely like it does for the polling.
Of course, if the plugin wants to be very defensive, I must admit that of course it's possible to play games with the counters and update them behind the scenes (even back in time). Although you technically can do that with changelist numbers as well, that series of numbers is always increasing.

I didn't mean actually using labels, I meant passing the changeset in as a parameter in the Label configuration field. When syncing, it'll use p4 sync //workspace/...@${label} where ${label} is expanded appropriately. So it doesn't matter if label is set to a changeset, or an actual label.

I don't think either of these methods will give you changelogs downstream, unfortunately. There's simply no way to accurately describe the state of the last sync when using labels or changesets. There might be a plugin for propagating changelogs downstream, however.

Parameters are expanded in the View and the Label configuration fields only. The parameters that are expanded are the ones defined by the "Parameterized Build" functionality. This doesn't include the built-in ones (eg, JOB_NAME) as far as I know.

Syncing to a label is not the problem; I think we do that for more than half of our jobs
The problem is rather actually labeling a build so a downstream job can sync to the same point in "time".
Right now, our build script runs a 'p4 label' command after the actual build. The label is always called the same, but moves forward in the changelist numbers. But as I've written in JENKINS-4928 this means that we lose changeset information downstream.
I might try one or both of these:

• Using a new label for all builds, and passing its name as a parameter downstream. A downside is the number of new labels this will result in. But will it give us changesets downstream?
• Using this counter-idea will eliminate the labels. But will it give us changesets downstream?
  A question (although it sort of feels like hijacking the issue): When are the parameters expanded? It seems slightly magic. Can I e.g. use JOB_NAME in client name?

Another quick note: This can also be accomplished by parameter substitution in the Label field of the perforce configuration. That will cause the plugin to sync to whatever changeset or label is passed into the build. That way you don't need any additional permissions on the perforce server.

Just a quick note (to self and others): The use of "p4 counter" requires that the Hudson Perforce user has "review" permissions. I'll see if I can grow one of those