[JIRA] (JENKINS-3265) Reload Configuration from Disk (or POSTing config.xml) loses info on running builds
Jeremy Frank commented on JENKINS-3265 Reload Configuration from Disk (or POSTing config.xml) loses info on running builds Any application can halt without warning, due to power out, hardware defect, OS bugs, malicious software, you-name-it, even well-intentioned code in the application itself. Therefore important state information must be persisted upon every change. Anything else risks losing that data. So by this logic, I agree that saving the state of running builds is "eminently reasonable" as you say. You have my vote . This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13879) Builds failing to trigger due to changelist number being set incorrectly
[
https://issues.jenkins-ci.org/browse/JENKINS-13879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[JIRA] (JENKINS-13899) Build History timeline is off by an hour (daylight savings issue?)
Jeremy Frank created JENKINS-13899: -- Summary: Build History timeline is off by an hour (daylight savings issue?) Key: JENKINS-13899 URL: https://issues.jenkins-ci.org/browse/JENKINS-13899 Project: Jenkins Issue Type: Bug Components: core, monitoring Environment: Jenkins 1.462, on IE8 and Firefox 3 Reporter: Jeremy Frank Priority: Minor Attachments: BuildRecord.png, Now.png, Timeline.png The build history timeline graph labels are off by an hour, perhaps due to daylight savings. Please see attachments for an example. -- 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
[JIRA] (JENKINS-13879) Builds failing to trigger due to changelist number being set incorrectly
[
https://issues.jenkins-ci.org/browse/JENKINS-13879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163166#comment-163166
]
Jeremy Frank commented on JENKINS-13879:
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
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
[JIRA] (JENKINS-13879) Builds failing to trigger due to changelist number being set incorrectly
Jeremy Frank created JENKINS-13879: -- Summary: 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 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
