[
https://issues.jenkins-ci.org/browse/JENKINS-13879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163162#comment-163162
]
Jeremy Frank commented on JENKINS-13879:
----------------------------------------
Hi Rob,
Thank you for the quick response.
Your suspicion about the fallback is correct. Please consider these two
situations:
# 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.\\
# 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.
> Builds failing to trigger due to changelist number being set incorrectly
> ------------------------------------------------------------------------
>
> Key: JENKINS-13879
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13879
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: Jenkins 1.462, Perforce plugin 1.3.13
> Reporter: Jeremy Frank
> Assignee: Rob Petti
>
> When a job is run, the Perforce plugin for Jenkins records a changelist
> number for the build instance. From that point forward, triggering additional
> builds via Perforce only happens when new changelists are submitted with
> numbers higher than the recorded changelist number. Great, except that the
> recorded changelist number may not be correct.
> For example, if the most recent changelists look like this (from "p4
> changelists -m 2"):
> Change 24083 on 2012/05/23 by rmercer@rmercer-DcsMain *pending* 'The
> adapter layer now returns D'
> Change 24082 on 2012/05/23 by reladmin@jenkins-aci-RILCinterion-QA-2
> 'Check in server build result fo'
> and a build starts (either via the Build Now button, or because of 24082
> being submitted), the Perforce plugin runs "p4 counter change" and records
> 24083 as the changelist number. Note that 24083 is a *pending* changelist.
> Further polling will fail to detect that 24083 was submitted. No build will
> result. Oops, the latest "reserved" changelist number was recorded, rather
> than the latest "submitted" changelist number.
> Often this problem is masked because new changelist numbers get generated
> upon a checkin, but not always. Perforce only renumbers a changelist upon
> checkin if there are intervening changelists.
> Suggested solution: Rather than using "p4 counter change" to detect the
> current changelist number, please use "p4 changelists -m 1 -s submitted".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
