We are using Hudson (1.398) and the Perforce plugin (1.1.14) to run continuous integration. The build gets initiated everytime there is a checkin with a Perforce trigger that calls:
wget "http://username:password@hudsonserver:8080/job/hudson_projname_test/buildWithParameters?token=SECRETTOKEN&CHANGENUM=315311&SUBMITTER=username"
The Hudson cosole looks like this:
Started by remote host 169.169.69.69
Using master perforce client: projname_a0_username_hudson
[hudson] $ /eda/perforce_2010.1/x86_64/bin/p4 workspace -o projname_a0_username_hudson
Last sync'd change: 315267
[hudson] $ /eda/perforce_2010.1/x86_64/bin/p4 counter change
[hudson] $ /eda/perforce_2010.1/x86_64/bin/p4 -s changes //projname_a0_username_hudson/...@315268,@315311
Sync'ing workspace to changelist 315267.
[hudson] $ /eda/p开发者_JAVA百科erforce_2010.1/x86_64/bin/p4 sync //projname_a0_username_hudson/...@315267
Sync complete, took 3956 ms
[hudson] $ /bin/sh -xe /tmp/hudson30156.sh
+ p4 sync @315311
+ runsim
The problem is that Hudson does not seem to be syncing to the last changelist but instead to the next to last changelist so I have to "manually" sync with the changelist that was passed in via the parameter. But b/c of this Hudson uses the wrong changelist when it notifies the submitter that they may have broken the build.
Has anyone else noticed this behavior with Hudson/Perforce and if so how did you fix it?
Check in triggers are executed before the change is actually committed (so the trigger can block it if necessary). So what's likely happening is that the build is launching and grabbing the latest available change, which doesn't include the one currently being submitted.
What you might want to do instead is write a checkin trigger script that will fork into the background, and wait 10-20 seconds or so before calling wget.
精彩评论