[JIRA] [core] (JENKINS-25777) Run.getTimestamp does not return when the build entered the queue
Willem Verstraeten
updated JENKINS-25777
Run.getTimestamp does not return when the build entered the queue
Change By:
Willem Verstraeten
(25/Nov/14 3:21 PM)
Description:
Thejavadocof
{{
Run#getTimestamp
}}
and
{{
Run#getStartTimeInMillis
}}
seemstoindicatethatgetTimestampreturnsthetimewhenthebuildwasscheduled.Ireadthisasenteredthequeue.Inpracticehowever,the{{getTimestamp}}methodseemstoreturnthetimewhentheitemleavesthequeue.Sothedifferencebetween{{getTimestamp}}and{{getStartTimeMillis}}isalwaysverysmall,evenifthebuildspenthoursinthequeue.Thismakesithardtoinvestigateifanyprojectsareexperiencingexcessivewaittimes.
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
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-25777) Run.getTimestamp does not return when the build entered the queue
Willem Verstraeten created JENKINS-25777 Run.getTimestamp does not return when the build entered the queue Issue Type: Bug Assignee: Unassigned Components: core Created: 25/Nov/14 3:20 PM Description: The javadoc of Run#getTimestamp and Run#getStartTimeInMillis seems to indicate that getTimestamp returns the time when the build was scheduled. I read this as 'entered the queue'. In practice however, the getTimestamp method seems to return the time when the item leaves the queue. So the difference between getTimestamp and getStartTimeMillis is always very small, even if the build spent hours in the queue. This makes it hard to investigate if any projects are experiencing excessive wait times. Environment: jenkins 1.548 Project: Jenkins Priority: Minor Reporter: Willem Verstraeten 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-13669) NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith
Willem Verstraeten
commented on JENKINS-13669
NPE in hudson.plugins.mercurial.MercurialSCM.compareRemoteRevisionWith
If the possiblyCachedRepo is null, it means there was an earler error updating or cloning the cache. The polling shouldn't try to continue in that case, but throw an exception.
For instance:
if (!requiresWorkspaceForPolling()) {
launcher = Hudson.getInstance().createLauncher(listener);
PossiblyCachedRepo possiblyCachedRepo = cachedSource(Hudson.getInstance(), launcher, listener, true);
if (possiblyCachedRepo == null) {
throw new IOException("Could not use cache to poll for changes. See error messages above for more details");
}
FilePath repositoryCache = new FilePath(new File(possiblyCachedRepo.getRepoLocation()));
return compare(launcher, listener, baseline, output, Hudson.getInstance(), repositoryCache);
}
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
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-3907) Mercurial updates on matrix projects aren't synced properly
Willem Verstraeten commented on JENKINS-3907 Mercurial updates on matrix projects arent synced properly I've got a pull request to fix this here : https://github.com/jenkinsci/mercurial-plugin/pull/34 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15829) hg share always recreating working copy on slave (on master it's working fine)
Willem Verstraeten commented on JENKINS-15829 hg share always recreating working copy on slave (on master its working fine) I think this is because the mercurial caches on the slave don't have a default path to push and pull from. Igor: could you, on your slave, create a .hg/hgrc file in the /app/agora/hudsonslave/hgcache/D38534FF4534AE3232A1AB292D5BA54825AE752B-AgoraLight that contains the following information: [paths] default=__URL_OF_YOUR_MASTER_REPO__ Does the working copy get recreated every time then, after you remove your workaround? 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-15829) hg share always recreating working copy on slave (on master it's working fine)
Willem Verstraeten commented on JENKINS-15829 hg share always recreating working copy on slave (on master its working fine) Igor: what do you mean with the 'fake working copy' option? I can find a 'custom workspace' option, is that it ? Also, are there any other builds (of other jobs) running between the first build on the slave and the second build ? 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
