[JIRA] (JENKINS-12533) Strict Parsing of Command Line Options Breaks Custom AuthenticationRealm Implementation
[
https://issues.jenkins-ci.org/browse/JENKINS-12533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Barbey resolved JENKINS-12533.
-
Resolution: Not A Defect
As explained in my last comment, we're now using the {{fileRealm.configFile}}
option.
Strict Parsing of Command Line Options Breaks Custom AuthenticationRealm
Implementation
---
Key: JENKINS-12533
URL: https://issues.jenkins-ci.org/browse/JENKINS-12533
Project: Jenkins
Issue Type: Bug
Components: core
Affects Versions: current
Environment: Ubuntu Server 9.04, for details see attached system info.
Reporter: Robert Barbey
Priority: Blocker
Labels: commandline, options, winstone
Attachments: System Information [Jenkins].html
We're are using a custom implementation of AuthenticationRealm for Winstone
to be able to reuse the same login credentials for all our tools like SVN,
trac, apache, and of course Jenkins. This implementation relies on a custom
option being set as part of the JENKINS_ARGS to find the apache-style
credentials file.
Due to the strict parsing of options introduced in 1.449 our custom
implementation is broken unless there is either another way to provide custom
options in a similar fashion or the strict parsing of options can be switched
off.
I think this problem is related to JENKINS-12521
===
[Winstone 2012/01/25 13:04:52] - Control thread shutdown successfully
Listening for transport dt_socket at address: 8042
Running from: /usr/share/jenkins/jenkins.war
Exception in thread main java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at Main._main(Main.java:273)
at Main.main(Main.java:98)
Caused by: java.lang.IllegalArgumentException: Unrecognized option:
--subversionGroupsRealm.configFile=/codebase/codebase.access
at winstone.cmdline.CmdLineParser.parse(CmdLineParser.java:53)
at winstone.Launcher.getArgsFromCommandLine(Launcher.java:391)
at winstone.Launcher.main(Launcher.java:359)
... 6 more
--
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-12660) Fail to start the windows service when trying to launch slave node
[
https://issues.jenkins-ci.org/browse/JENKINS-12660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158721#comment-158721
]
Alexis Morelle commented on JENKINS-12660:
--
Had the same today installing a Windows Server 2008 R2 x64 node using the local
admin account.
However, I added another node with the same OS to the same Master successfully
this morning too but with a domain account.
Fail to start the windows service when trying to launch slave node
--
Key: JENKINS-12660
URL: https://issues.jenkins-ci.org/browse/JENKINS-12660
Project: Jenkins
Issue Type: Bug
Components: slave-setup
Affects Versions: current
Environment: Master : Redhat 5
Slave Node : Win7 x64
Reporter: Rico ZHANG
Assignee: Kohsuke Kawaguchi
We used to be able to launch the slave node successfully, but it did not work
since we upgraded the jenkins to latest version (1.449)
It doesn't dump any exception to the console, but I captured the output:
{noformat}
Connecting to 192.168.160.62
Checking if Java exists
java full version 1.7.0-b147
Installing the Jenkins slave service
Copying jenkins-slave.exe
Copying slave.jar
Copying jenkins-slave.xml
Registering the service
ERROR: Failed to create a service: Status Invalid Service Account
...
{noformat}
--
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-12660) Fail to start the windows service when trying to launch slave node
[
https://issues.jenkins-ci.org/browse/JENKINS-12660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158721#comment-158721
]
Alexis Morelle edited comment on JENKINS-12660 at 2/7/12 11:01 AM:
---
Had the same today installing a Windows Server 2008 R2 x64 node using the local
admin account.
However, I added another node with the same OS to the same Master successfully
this morning too but with a domain account.
Master is 1.444
was (Author: almorelle):
Had the same today installing a Windows Server 2008 R2 x64 node using the
local admin account.
However, I added another node with the same OS to the same Master successfully
this morning too but with a domain account.
Fail to start the windows service when trying to launch slave node
--
Key: JENKINS-12660
URL: https://issues.jenkins-ci.org/browse/JENKINS-12660
Project: Jenkins
Issue Type: Bug
Components: slave-setup
Affects Versions: current
Environment: Master : Redhat 5
Slave Node : Win7 x64
Reporter: Rico ZHANG
Assignee: Kohsuke Kawaguchi
We used to be able to launch the slave node successfully, but it did not work
since we upgraded the jenkins to latest version (1.449)
It doesn't dump any exception to the console, but I captured the output:
{noformat}
Connecting to 192.168.160.62
Checking if Java exists
java full version 1.7.0-b147
Installing the Jenkins slave service
Copying jenkins-slave.exe
Copying slave.jar
Copying jenkins-slave.xml
Registering the service
ERROR: Failed to create a service: Status Invalid Service Account
...
{noformat}
--
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-12667) No possibility to specify Workspace Root Directory for Slave node
Oleksandr Popov created JENKINS-12667: - Summary: No possibility to specify Workspace Root Directory for Slave node Key: JENKINS-12667 URL: https://issues.jenkins-ci.org/browse/JENKINS-12667 Project: Jenkins Issue Type: Bug Components: slave-setup Affects Versions: current Environment: Jenkins 1.450 Reporter: Oleksandr Popov Assignee: Kohsuke Kawaguchi There is no possibility to specify Workspace Root Directory for Slave node as it is for Master node. -- 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-5497) OutOfMemoryError: GC overhead limit exceeded
[ https://issues.jenkins-ci.org/browse/JENKINS-5497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158727#comment-158727 ] evernat commented on JENKINS-5497: -- As said before, there was activity even in the morning when there was nobody working. Having no more information from the reporter, resolving the issue as incomplete. OutOfMemoryError: GC overhead limit exceeded Key: JENKINS-5497 URL: https://issues.jenkins-ci.org/browse/JENKINS-5497 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: java -Xmx1500M -Xms1500M -ea -jar /home/hudson/hudson/hudson.war Red Hat Desktop release 4 (Nahant Update 3) java version 1.6.0_16 Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode) Reporter: rickb007 Priority: Minor Attachments: 20100129-1521.log.gz This out of memory error occurred early in the morning when nothing much else was happening and may therefore indicate a memory leak. The server had been up for five days without any other problem being noticed, and is generally very reliable. I have attached the whole log file; the first OutOfMemory error occurs about half way down and is followed by many others; then other problems arise as a consequence (these are unlikely to be bugs too). I have set the priority of this issue to 'minor' because it has not happened before, even though it crashed the server in this case. (Aside: why's it called 'priority'? it's a *severity*; don't people know the difference?) -- 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-12668) Slave uses wrong workspace for building a project and fails
tasat bar created JENKINS-12668:
---
Summary: Slave uses wrong workspace for building a project and
fails
Key: JENKINS-12668
URL: https://issues.jenkins-ci.org/browse/JENKINS-12668
Project: Jenkins
Issue Type: Bug
Components: master-slave
Affects Versions: current
Environment: Suse Linux 11.x 64 bit,
Reporter: tasat bar
I want the Jenkins master to build a small project on a slave.
Slave and Master run Suse Linux.
The same user (hans) which runs Jenkins is available on both machines and has
rw permissions on the slave's remote working directory (/var/jenkins).
The slave agent is launched on the slave ('ttvm3').
Building the project locally works.
When I configure the project to be build on the slave, it fails. The console
output on the master is:
{quote}
Started by user anonymous
Building on master in workspace /home/hans/.jenkins/jobs/testproject/workspace
Checkout:workspace / /home/hans/.jenkins/jobs/testproject/workspace -
hudson.remoting.LocalChannel@11b1e39
Using strategy: Default
Last Built Revision: Revision 97957e558fed7d0b116950e09dec1c248d1d0b54
(origin/HEAD, origin/master)
Checkout:workspace / /home/hans/.jenkins/jobs/testproject/workspace -
hudson.remoting.LocalChannel@11b1e39
Fetching changes from 1 remote Git repository
Fetching upstream changes from blablabla
Commencing build of Revision 69e242182e55e57b56c836a9c3a34f0232e5d56c
(origin/master)
Checking out Revision 69e242182e55e57b56c836a9c3a34f0232e5d56c (origin/master)
Triggering ttvm3
ttvm3 completed with result FAILURE
Finished: FAILURE
{quote}
The output on the slave for this build is:
{quote}
Started by upstream project testproject build number 29
Building remotely on ttvm3 in workspace /ttvm3
java.io.IOException: Failed to mkdirs: /ttvm3
at hudson.FilePath.mkdirs(FilePath.java:847)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1193)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:576)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465)
at hudson.model.Run.run(Run.java:1409)
at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Finished: FAILURE
{quote}
It seems as if Jenkins wants to create a directory called ttvm3 (which is the
name of the slave) in the root directory of the slave.
When I (just for the fun of it) create the directory /ttvm3 on the slave and
build the project again, the output for this build on the slave is:
{quote}
Started by upstream project testproject build number 30
Building remotely on ttvm3 in workspace /ttvm3
Checkout:ttvm3 / /ttvm3 - hudson.remoting.Channel@c4931d:ttvm3
Using strategy: Default
Checkout:ttvm3 / /ttvm3 - hudson.remoting.LocalChannel@146c0f
Cloning the remote Git repository
Cloning repository origin
ERROR: Failed to clean the workspace
java.io.IOException: Unable to delete /ttvm3
at hudson.Util.deleteFile(Util.java:237)
at hudson.Util.deleteRecursive(Util.java:287)
at hudson.FilePath$9.invoke(FilePath.java:856)
at hudson.FilePath$9.invoke(FilePath.java:854)
at hudson.FilePath.act(FilePath.java:788)
at hudson.FilePath.act(FilePath.java:770)
at hudson.FilePath.deleteRecursive(FilePath.java:854)
at hudson.plugins.git.GitAPI.clone(GitAPI.java:205)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1027)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:968)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2099)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
ERROR: Error cloning remote repo 'origin' : Failed to delete workspace
ERROR: Cause: Unable to delete /ttvm3
Trying next repository
ERROR: Could not clone repository
FATAL: Could not clone
hudson.plugins.git.GitException: Could not clone
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1042)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:968)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2099)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at
[JIRA] (JENKINS-3105) Configuration UI to disable process tree killer selectively
[ https://issues.jenkins-ci.org/browse/JENKINS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158732#comment-158732 ] m_broida edited comment on JENKINS-3105 at 2/7/12 5:43 PM: --- Details on this workaround work, please? Does it prevent intentionally killing/aborting a build? Can a build step in the job just set a BUILD_ID envvar? Is the specific value dontKillMe required, or will any value work? Adding a parameter to every one of our many jobs (and new ones) would be a hassle, even if users could accept a default value. Can the BUILD_ID envvar be set in the overall Jenkins configuration to affect all Jenkins jobs? Can the BUILD_ID envvar be set at the OS level to affect all Jenkins jobs? We have had to restrict many of our jobs to run on nodes with only a single executor to ensure that the situation doesn't arise. A real fix would be most helpful. was (Author: m_broida): Details on this workaround work, please? Can a build step in the job just set a BUILD_ID envvar? Is the specific value dontKillMe required, or will any value work? Adding a parameter to every one of our many jobs (and new ones) would be a hassle, even if users could accept a default value. Can the BUILD_ID envvar be set in the overall Jenkins configuration to affect all Jenkins jobs? Can the BUILD_ID envvar be set at the OS level to affect all Jenkins jobs? We have had to restrict many of our jobs to run on nodes with only a single executor to ensure that the situation doesn't arise. A real fix would be most helpful. Configuration UI to disable process tree killer selectively --- Key: JENKINS-3105 URL: https://issues.jenkins-ci.org/browse/JENKINS-3105 Project: Jenkins Issue Type: Improvement Components: other Affects Versions: current Environment: Platform: Sun, OS: Solaris Reporter: olamy Priority: Trivial Due to fix https://hudson.dev.java.net/issues/show_bug.cgi?id=2729, I can't restart my tomcat instance with using a script which worked fine before 1.283. My script called fastRestart.sh is : PWD=`pwd` cd $PWD #BUILD_ID=dontKillMe catalina.sh start #BUILD_ID=dontKillMe ./startup.sh echo $BUILD_ID kill -9 `cat ./tomcat.pid` ./startup.sh My hudson job do : BUILD_ID=dontKillMe startup.sh cd /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin ./fastRestart.sh job console output : started [workspace] $ /bin/sh -xe /local/dotw/tmp/hudson-tmp/hudson3776950102996593394.sh BUILD_ID=dontKillMe startup.sh + cd /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin + ./fastRestart.sh + pwd PWD=/local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin + cd /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin + echo dontKillMe startup.sh dontKillMe startup.sh + cat ./tomcat.pid + kill -9 9822 + ./startup.sh finished: SUCCESS Here the tomcat has been killed and restarted but immediatly stop due to fix for 2729. Is there any other workaround ? IMHO we should have a flag when running a script which don't kill child processes (to preserve a minimum of backward compatibility and a minimum of some jobs/scripts rewriting) Thanks -- Olivier -- 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-12586) cvs-plugin fails to read old changelog files
[ https://issues.jenkins-ci.org/browse/JENKINS-12586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158735#comment-158735 ] Amir Isfy commented on JENKINS-12586: - Having the same probelm. cvs-plugin fails to read old changelog files Key: JENKINS-12586 URL: https://issues.jenkins-ci.org/browse/JENKINS-12586 Project: Jenkins Issue Type: Bug Components: cvs Affects Versions: current Environment: jenkins 1.449, cvs-plugin 2.0 Reporter: Alex Lehmann Priority: Minor after updating to cvs-plugin 2.0, I get an exception when parsing the old changelog files that were written by the previous version of the plugin, e.g. Caused by: java.text.ParseException: Unparseable date: 2011-12-14 at java.text.DateFormat.parse(DateFormat.java:337) at hudson.scm.CVSChangeLogSet$CVSChangeLog.setDate(CVSChangeLogSet.java:232) ... 34 more the corresponding changelog entry looks like this changelog entry date2011-12-14/date time23:26/time -- 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-12628) Executable file permission not set anymore
[ https://issues.jenkins-ci.org/browse/JENKINS-12628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158738#comment-158738 ] Michael Clarke commented on JENKINS-12628: -- The cvs client doesn't do anything with permission just now. It's possible to use File.setExecutable() providing I can work out what response from the server specifies the permission. There is an outstanding Netbeans issues for this which no-one seems to have done any work on (I don't have the details to hand though). Executable file permission not set anymore -- Key: JENKINS-12628 URL: https://issues.jenkins-ci.org/browse/JENKINS-12628 Project: Jenkins Issue Type: Bug Components: cvs Environment: CentOS release 5.7 (affected system, Slave), Windows Server 2003 (Master) Reporter: Marco Borm Fix For: current Updating the cvs plugin from 1.6 to 2.0 breaks all our linux builds, due the fact that our compile scripts don't have executable permission bit set anymore. The bit is correctly set on the affected files on cvs server side. cvs plugin 1.6: -rwxrwx--- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release cvs plugin 2.0: -rw-rw-r-- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release -- 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-12186) warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does)
[ https://issues.jenkins-ci.org/browse/JENKINS-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner resolved JENKINS-12186. --- Resolution: Fixed warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does) - Key: JENKINS-12186 URL: https://issues.jenkins-ci.org/browse/JENKINS-12186 Project: Jenkins Issue Type: Improvement Components: analysis-collector Affects Versions: current Reporter: Greg Moncreaff Assignee: Ulli Hafner E.g. if you aren't looking at Java code, then Findbugs and Checkstyle and PMD don't have any value. When new things are tied into analysis core, it will be even more important to allow reasonable display filtering -- 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-12662) Contolling (disabling/enabling) a build step by a flag
[ https://issues.jenkins-ci.org/browse/JENKINS-12662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner resolved JENKINS-12662. --- Resolution: Fixed There is a plugin for that: flexible build step. Contolling (disabling/enabling) a build step by a flag --- Key: JENKINS-12662 URL: https://issues.jenkins-ci.org/browse/JENKINS-12662 Project: Jenkins Issue Type: New Feature Components: tasks-plugin Affects Versions: current Environment: Windows 7 Reporter: Kaushal Kumar Assignee: Ulli Hafner Sometimes we need to disable a build step without deleting the build step from the Job. I couldn't find anything like this. Could you please help me in finding this, else consider this as a new feature and add it. Kaushal -- 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-12482) Warnings not detected when file path does not appear after [WARNING]
[
https://issues.jenkins-ci.org/browse/JENKINS-12482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158744#comment-158744
]
Ulli Hafner commented on JENKINS-12482:
---
Ok, I see. Seems that I need to add an additional parser for Java 7 (or extend
the current one). Can you please attach the warnings from your comment above as
a file? Seems that not all white space characters are preserved in the comment.
Warnings not detected when file path does not appear after [WARNING]
Key: JENKINS-12482
URL: https://issues.jenkins-ci.org/browse/JENKINS-12482
Project: Jenkins
Issue Type: Bug
Components: warnings
Affects Versions: current
Environment: ubuntu, java 1.7.0_02, tomcat7, jenkins 1.447, warnings
plugin v3.26, maven-compiler-plugin v2.3.2
Reporter: Stefan Thurnherr
Assignee: Ulli Hafner
When compiling a Java project using the javac compiler, most of the warnings
in my console log appear as follows:
{noformat}
[WARNING] BasicTableInfo
/absolute/path/to/source/File.java:[143,66] [unchecked] unchecked conversion
{noformat}
and are thus not picked up by the warnings plugin.
When there is no additional token before the source file path, such as in the
following warning:
{noformat}
[WARNING] /absolute/path/to/source/File.java:[181,69] [unchecked] unchecked
cast
{noformat}
then the warning is correctly picked up by the warnings plugin.
Btw: Coloring in the console log has the same bug: when the path appears as
the first token (after [WARNING]), then the path and the next token (warning
category) are highlighted in dark-yellow. When there is an additional token
before the path, only that additional token is highlighted in dark-yellow
(not the path and subsequent tokens).
--
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-12424) More correct and specific build state change reasons from Warnings
[
https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158745#comment-158745
]
Ulli Hafner edited comment on JENKINS-12424 at 2/7/12 9:19 PM:
---
Ok, I added the message to the build summary:
{code}
BuildResultEvaluator.failure.new.priority={0} new warnings of priority {3}
exceeded the threshold of {1} by {2}
BuildResultEvaluator.failure.all.priority={0} warnings of priority {3} exceed
the threshold of {1} by {2}
BuildResultEvaluator.failure.new={0} new warnings exceeded the threshold of {1}
by {2}
BuildResultEvaluator.failure.all={0} warnings exceed the threshold of {1} by {2}
{code}
Can you please check if these messages are ok (and correct English)? The
numbers in the brackets are replaced by values.
was (Author: drulli):
Ok, I added the message to the build summary:
{code}
BuildResultEvaluator.failure.new.priority={0} new warnings of priority {3}
exceeded the threshold of {1} by {2}
BuildResultEvaluator.failure.all.priority={0} warnings of priority {3} exceed
the threshold of {1} by {2}
BuildResultEvaluator.failure.new={0} new warnings exceeded the threshold of {1}
by {2}
BuildResultEvaluator.failure.all={0} warnings exceed the threshold of {1} by {2}
{code}
Can you please check if these messages are ok (and correct english)? The
numbers in the brackets are replaced by values.
More correct and specific build state change reasons from Warnings
---
Key: JENKINS-12424
URL: https://issues.jenkins-ci.org/browse/JENKINS-12424
Project: Jenkins
Issue Type: Improvement
Components: analysis-core, warnings
Reporter: Greg Moncreaff
Assignee: Ulli Hafner
Priority: Minor
I got this in my jobs console.
[WARNINGS] Setting build status to FAILURE since total number of annotations
exceeds the threshold 200: [HIGH, NORMAL, LOW]
Two issues.
1. text says total, but this was actually a compute status since reference
build (new) gate.
2. text should say which specific criteria was exceeded
3. it doesn't tell you what the actual number/difference was
E.g.
[WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH
annotations exceeds the threshold of 200 by 34 or 17%.
--
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-12424) More correct and specific build state change reasons from Warnings
[
https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158745#comment-158745
]
Ulli Hafner edited comment on JENKINS-12424 at 2/7/12 9:21 PM:
---
Ok, I added the message to the build summary:
{code}
BuildResultEvaluator.failure.new.priority={0} new warnings of priority {3}
exceed the threshold of {1} by {2}
BuildResultEvaluator.failure.all.priority={0} warnings of priority {3} exceed
the threshold of {1} by {2}
BuildResultEvaluator.failure.new={0} new warnings exceed the threshold of {1}
by {2}
BuildResultEvaluator.failure.all={0} warnings exceed the threshold of {1} by {2}
{code}
Can you please check if these messages are ok (and correct English)? The
numbers in the brackets are replaced by values.
was (Author: drulli):
Ok, I added the message to the build summary:
{code}
BuildResultEvaluator.failure.new.priority={0} new warnings of priority {3}
exceeded the threshold of {1} by {2}
BuildResultEvaluator.failure.all.priority={0} warnings of priority {3} exceed
the threshold of {1} by {2}
BuildResultEvaluator.failure.new={0} new warnings exceeded the threshold of {1}
by {2}
BuildResultEvaluator.failure.all={0} warnings exceed the threshold of {1} by {2}
{code}
Can you please check if these messages are ok (and correct English)? The
numbers in the brackets are replaced by values.
More correct and specific build state change reasons from Warnings
---
Key: JENKINS-12424
URL: https://issues.jenkins-ci.org/browse/JENKINS-12424
Project: Jenkins
Issue Type: Improvement
Components: analysis-core, warnings
Reporter: Greg Moncreaff
Assignee: Ulli Hafner
Priority: Minor
I got this in my jobs console.
[WARNINGS] Setting build status to FAILURE since total number of annotations
exceeds the threshold 200: [HIGH, NORMAL, LOW]
Two issues.
1. text says total, but this was actually a compute status since reference
build (new) gate.
2. text should say which specific criteria was exceeded
3. it doesn't tell you what the actual number/difference was
E.g.
[WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH
annotations exceeds the threshold of 200 by 34 or 17%.
--
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-12424) More correct and specific build state change reasons from Warnings
[
https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158745#comment-158745
]
Ulli Hafner commented on JENKINS-12424:
---
Ok, I added the message to the build summary:
{code}
BuildResultEvaluator.failure.new.priority={0} new warnings of priority {3}
exceeded the threshold of {1} by {2}
BuildResultEvaluator.failure.all.priority={0} warnings of priority {3} exceed
the threshold of {1} by {2}
BuildResultEvaluator.failure.new={0} new warnings exceeded the threshold of {1}
by {2}
BuildResultEvaluator.failure.all={0} warnings exceed the threshold of {1} by {2}
{code}
Can you please check if these messages are ok (and correct english)? The
numbers in the brackets are replaced by values.
More correct and specific build state change reasons from Warnings
---
Key: JENKINS-12424
URL: https://issues.jenkins-ci.org/browse/JENKINS-12424
Project: Jenkins
Issue Type: Improvement
Components: analysis-core, warnings
Reporter: Greg Moncreaff
Assignee: Ulli Hafner
Priority: Minor
I got this in my jobs console.
[WARNINGS] Setting build status to FAILURE since total number of annotations
exceeds the threshold 200: [HIGH, NORMAL, LOW]
Two issues.
1. text says total, but this was actually a compute status since reference
build (new) gate.
2. text should say which specific criteria was exceeded
3. it doesn't tell you what the actual number/difference was
E.g.
[WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH
annotations exceeds the threshold of 200 by 34 or 17%.
--
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-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158746#comment-158746 ] Greg Moncreaff commented on JENKINS-12424: -- Messages look fine. Thank you for doing this! More correct and specific build state change reasons from Warnings --- Key: JENKINS-12424 URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 Project: Jenkins Issue Type: Improvement Components: analysis-core, warnings Reporter: Greg Moncreaff Assignee: Ulli Hafner Priority: Minor I got this in my jobs console. [WARNINGS] Setting build status to FAILURE since total number of annotations exceeds the threshold 200: [HIGH, NORMAL, LOW] Two issues. 1. text says total, but this was actually a compute status since reference build (new) gate. 2. text should say which specific criteria was exceeded 3. it doesn't tell you what the actual number/difference was E.g. [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH annotations exceeds the threshold of 200 by 34 or 17%. -- 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-12672) Jobs take a long time to complete - get stuck sending success/failure email
Ed Palazzo created JENKINS-12672: Summary: Jobs take a long time to complete - get stuck sending success/failure email Key: JENKINS-12672 URL: https://issues.jenkins-ci.org/browse/JENKINS-12672 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: Jenkins 1.450 Perforce plugin 1.3.7 Red Hat Enterprise Linux 4.5 Reporter: Ed Palazzo We've noticed that sometimes our jobs get in a state where they're taking a long time to complete. Investigation reveals that the maven build has completing successfully, and it's stuck trying to send a success email. Left alone, the build will eventually complete but a 10 minute build may take several hours to succeed and blocks other jobs since the executors are busy. Manual monitoring and intervention is usually required to free up the jobs. Here's an example thread taken from a Jenkins thread dump that shows the stuck job. It appears to be processing the change list to retrieve the checkin user(s) that checked in code. Why is this taking so long? The exact stack changes with each thread dump, but it is consistent up to PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111). Executor #2 for master : executing markview-7.0.x_document-server #103 prio=10 tid=0x48865400 nid=0x5109 runnable [0x49bfa000] java.lang.Thread.State: RUNNABLE at java.util.ArrayList.size(ArrayList.java:177) at org.dom4j.tree.BackedList.init(BackedList.java:36) at org.dom4j.tree.AbstractBranch.createResultList(AbstractBranch.java:373) at org.dom4j.tree.AbstractElement.elements(AbstractElement.java:392) at org.dom4j.tree.AbstractElement.elementIterator(AbstractElement.java:428) at org.jaxen.dom4j.DocumentNavigator.getChildAxisIterator(DocumentNavigator.java:233) at org.jaxen.expr.iter.IterableChildAxis.namedAccessIterator(IterableChildAxis.java:98) at org.jaxen.expr.DefaultNameStep.evaluate(DefaultNameStep.java:180) at org.jaxen.expr.DefaultLocationPath.evaluate(DefaultLocationPath.java:140) at org.jaxen.expr.DefaultXPathExpr.asList(DefaultXPathExpr.java:102) at org.jaxen.BaseXPath.selectNodesForContext(BaseXPath.java:674) at org.jaxen.BaseXPath.selectNodes(BaseXPath.java:213) at org.jaxen.BaseXPath.selectSingleNode(BaseXPath.java:234) at org.dom4j.xpath.DefaultXPath.selectSingleNode(DefaultXPath.java:159) at org.dom4j.tree.AbstractNode.selectSingleNode(AbstractNode.java:185) at hudson.plugins.perforce.PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111) at hudson.plugins.perforce.PerforceChangeLogParser.parse(PerforceChangeLogParser.java:18) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:808) at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:782) at hudson.model.AbstractBuild.hasParticipant(AbstractBuild.java:356) at hudson.model.AbstractProject.hasParticipant(AbstractProject.java:1366) at hudson.model.User.getProjects(User.java:402) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:38) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675) at hudson.maven.MavenModuleSetBuild$RunnerImpl.cleanUp(MavenModuleSetBuild.java:1022) at hudson.model.Run.run(Run.java:1453) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) -- 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-12673) Can't install apk and adb devices shows there is no device/emulator
Kevin Chow created JENKINS-12673: Summary: Can't install apk and adb devices shows there is no device/emulator Key: JENKINS-12673 URL: https://issues.jenkins-ci.org/browse/JENKINS-12673 Project: Jenkins Issue Type: New Feature Components: android-emulator Environment: OSX Reporter: Kevin Chow Assignee: Christopher Orr I use Install Android Package Option in Build Step Before running the installer, I did adb devices and it's showing the emulator + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices 15:50:37 List of devices attached 15:50:37 localhost:49651 device 15:50:37 15:50:37 [android] Installing APK file 'EM_Runtime.apk' 15:50:37 $ /tmp/jenkins/tools/android-sdk/platform-tools/adb -s localhost:49651 install -r Runtime.apk 15:50:47 729 KB/s (7369965 bytes in 9.870s) 15:50:50pkg: /data/local/tmp/Runtime.apk 15:51:27 - waiting for device - It's supposed to show Succeed which is not. I tried to run this again: + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices It would just restart adb. Is it a known issue? Anyway that I could resolve it? -- 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-12673) Can't install apk and adb devices shows there is no device/emulator
[ https://issues.jenkins-ci.org/browse/JENKINS-12673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158750#comment-158750 ] Christopher Orr commented on JENKINS-12673: --- How are you starting the emulator? Using the plugin, or via some other means? Which plugin version? Can you possibly post all/more of the build log, including the start and anything else Android- or adb-related. Thanks. Can't install apk and adb devices shows there is no device/emulator --- Key: JENKINS-12673 URL: https://issues.jenkins-ci.org/browse/JENKINS-12673 Project: Jenkins Issue Type: New Feature Components: android-emulator Environment: OSX Reporter: Kevin Chow Assignee: Christopher Orr I use Install Android Package Option in Build Step Before running the installer, I did adb devices and it's showing the emulator + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices 15:50:37 List of devices attached 15:50:37 localhost:49651 device 15:50:37 15:50:37 [android] Installing APK file 'EM_Runtime.apk' 15:50:37 $ /tmp/jenkins/tools/android-sdk/platform-tools/adb -s localhost:49651 install -r Runtime.apk 15:50:47 729 KB/s (7369965 bytes in 9.870s) 15:50:50 pkg: /data/local/tmp/Runtime.apk 15:51:27 - waiting for device - It's supposed to show Succeed which is not. I tried to run this again: + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices It would just restart adb. Is it a known issue? Anyway that I could resolve it? -- 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-12672) Jobs take a long time to complete - get stuck sending success/failure email
[ https://issues.jenkins-ci.org/browse/JENKINS-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158751#comment-158751 ] Rob Petti commented on JENKINS-12672: - Ok, I see what's happening here. Mail resolvers aren't given a hint as to which project to look at when determining the email address, so unfortunately this means that we need to know which projects that user has ever committed changes to. The project is needed so the plugin knows what settings to use to connect to perforce and obtain the email address. It would seem that the problem lies with the User.getProjects() function that we use to get the list of candidates. It will run through every single changelog in every single project. I imagine this is taking a long time because you have a lot of builds. Jobs take a long time to complete - get stuck sending success/failure email --- Key: JENKINS-12672 URL: https://issues.jenkins-ci.org/browse/JENKINS-12672 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: Jenkins 1.450 Perforce plugin 1.3.7 Red Hat Enterprise Linux 4.5 Reporter: Ed Palazzo We've noticed that sometimes our jobs get in a state where they're taking a long time to complete. Investigation reveals that the maven build has completing successfully, and it's stuck trying to send a success email. Left alone, the build will eventually complete but a 10 minute build may take several hours to succeed and blocks other jobs since the executors are busy. Manual monitoring and intervention is usually required to free up the jobs. Here's an example thread taken from a Jenkins thread dump that shows the stuck job. It appears to be processing the change list to retrieve the checkin user(s) that checked in code. Why is this taking so long? The exact stack changes with each thread dump, but it is consistent up to PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111). Executor #2 for master : executing markview-7.0.x_document-server #103 prio=10 tid=0x48865400 nid=0x5109 runnable [0x49bfa000] java.lang.Thread.State: RUNNABLE at java.util.ArrayList.size(ArrayList.java:177) at org.dom4j.tree.BackedList.init(BackedList.java:36) at org.dom4j.tree.AbstractBranch.createResultList(AbstractBranch.java:373) at org.dom4j.tree.AbstractElement.elements(AbstractElement.java:392) at org.dom4j.tree.AbstractElement.elementIterator(AbstractElement.java:428) at org.jaxen.dom4j.DocumentNavigator.getChildAxisIterator(DocumentNavigator.java:233) at org.jaxen.expr.iter.IterableChildAxis.namedAccessIterator(IterableChildAxis.java:98) at org.jaxen.expr.DefaultNameStep.evaluate(DefaultNameStep.java:180) at org.jaxen.expr.DefaultLocationPath.evaluate(DefaultLocationPath.java:140) at org.jaxen.expr.DefaultXPathExpr.asList(DefaultXPathExpr.java:102) at org.jaxen.BaseXPath.selectNodesForContext(BaseXPath.java:674) at org.jaxen.BaseXPath.selectNodes(BaseXPath.java:213) at org.jaxen.BaseXPath.selectSingleNode(BaseXPath.java:234) at org.dom4j.xpath.DefaultXPath.selectSingleNode(DefaultXPath.java:159) at org.dom4j.tree.AbstractNode.selectSingleNode(AbstractNode.java:185) at hudson.plugins.perforce.PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111) at hudson.plugins.perforce.PerforceChangeLogParser.parse(PerforceChangeLogParser.java:18) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:808) at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:782) at hudson.model.AbstractBuild.hasParticipant(AbstractBuild.java:356) at hudson.model.AbstractProject.hasParticipant(AbstractProject.java:1366) at hudson.model.User.getProjects(User.java:402) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:38) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at
[JIRA] (JENKINS-12456) Automatic deploy script should be deployed only on machines with specific labels
[ https://issues.jenkins-ci.org/browse/JENKINS-12456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Lavoie updated JENKINS-12456: - Description: Plugin that deploys itself automatically on slaves should only deploy if the slave has some specific labels. The use case here is that not all our slaves might be related to the plugin it wants to be installed on. The labels could start with jenkins-plugin- so we know it's for a jenkins plugin and it could add the plugin name after that prefix so we know which plugin it is. This can be applied to hadoop as well as ChromeDriver unless it uses the configuration of selenium grid v2 exclude pattern configuration which is not the case in the trunk. Unless this feature can be controlled somewhere that I've not seen, this is pretty bad to install some stuff on machines that don't need it or will fail to work because the distant machine is not compatible with the plugin was: Plugin that deploys itself automatically on slaves should only deploy if the slave has some specific labels. The use case here is that not all our slaves might be related to the plugin it wants to be installed on. The labels could start with jenkins-plugin- so we know it's for a jenkins plugin and it could add the plugin name after that prefix so we know which plugin it is. This can be applied to hadoop as well as ChromeDriver unless it uses the configuration of selenium grid v2 exclude pattern configuration which is not the case in the trunk. Unless this feature can be controlled somewhere that I've not seen, this is pretty bad to install some stuff on machines that don't need it or will fail to work because the distant machine is not compatible with the plugin (ChromeDriver is useless on a unix non-gui slave) Automatic deploy script should be deployed only on machines with specific labels Key: JENKINS-12456 URL: https://issues.jenkins-ci.org/browse/JENKINS-12456 Project: Jenkins Issue Type: Improvement Components: plugin Environment: linux ubuntu, Jenkins 1.448 Reporter: Richard Lavoie Labels: ChromeDriver, Selenium, hadoop Plugin that deploys itself automatically on slaves should only deploy if the slave has some specific labels. The use case here is that not all our slaves might be related to the plugin it wants to be installed on. The labels could start with jenkins-plugin- so we know it's for a jenkins plugin and it could add the plugin name after that prefix so we know which plugin it is. This can be applied to hadoop as well as ChromeDriver unless it uses the configuration of selenium grid v2 exclude pattern configuration which is not the case in the trunk. Unless this feature can be controlled somewhere that I've not seen, this is pretty bad to install some stuff on machines that don't need it or will fail to work because the distant machine is not compatible with the plugin -- 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-12388) Crontab @yearly and @anually are never triggered in 1.448 RC
[ https://issues.jenkins-ci.org/browse/JENKINS-12388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] OHTAKE Tomohiro resolved JENKINS-12388. --- Resolution: Fixed Crontab @yearly and @anually are never triggered in 1.448 RC Key: JENKINS-12388 URL: https://issues.jenkins-ci.org/browse/JENKINS-12388 Project: Jenkins Issue Type: Bug Components: core Environment: Jenkins 1.448 RC Reporter: OHTAKE Tomohiro Assignee: OHTAKE Tomohiro Steps to reproduce: # Install Jenkins 1.448 RC # Create a free-style job and set its Build periodically schedule to @yearly # Stop Jenkins # Adjuest server's time to 2012-12-31 23:55 # Start Jenkins # Wait until 2013-01-01, but the job is not triggerd @yearly and @annually were interpreted to 0 0 1 1 * by Jenkins 1.447. On the other hand they are interpreted to H H H H * by Jenkins 1.448 RC and H are hashed to 0 0 1 0 *. Since there is no chanse for month to be 0, @yearly and @annually are never triggered in 1.448 RC. Workaround: Instead of @yearly and @annually, use 0 0 1 1 *. If JENKINS-12356 is fixed, this issue will be also fixed. -- 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-3788) No artifacts are recorded. Is this a Maven project? only for parallel builds
[ https://issues.jenkins-ci.org/browse/JENKINS-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158754#comment-158754 ] Simon van der Sluis commented on JENKINS-3788: -- We have the same problem. Since our build takes a little over an hour we would really benefit if we could build the modules in parallel. Also can anyone tell me what the help note means: 'When your build uses aggregator-style multi-module aware mojos, you'd have to leave this option unchecked so that the mojo will have access to all of your modules.' No artifacts are recorded. Is this a Maven project? only for parallel builds -- Key: JENKINS-3788 URL: https://issues.jenkins-ci.org/browse/JENKINS-3788 Project: Jenkins Issue Type: Bug Components: maven2 Affects Versions: current Environment: Platform: All, OS: All Reporter: jparent I recently enable deployment to a repo post-build action. The deploying part works fine but whenever I activate parallel builds things go wrong. The top level --aka parent -- pom.xml obviously has no artifact to deploy and so the build is marked as failed pretty quickly. That's a problem :( Disable parallel builds and it works! Note that despite the build being marked a failed Hudson still launches the parallel compilation of the modules -- 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-12017) Seriously slow rendering/loading times for the job/foo/configure page
[ https://issues.jenkins-ci.org/browse/JENKINS-12017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158755#comment-158755 ] James Randolph commented on JENKINS-12017: -- Nope, I'm seeing horrible page load times in general. My research led me here. Loading a job's config page can take up to a minute we have a fairly naked instance with 19 plugins Seriously slow rendering/loading times for the job/foo/configure page - Key: JENKINS-12017 URL: https://issues.jenkins-ci.org/browse/JENKINS-12017 Project: Jenkins Issue Type: Bug Components: core Reporter: R. Tyler Croy Opening a placeholder ticket for everybody from IRC to add numbers from their own installations loading the configure page. I think useful information to include would be: * Wall clock time from when we start to load the page until when it completes loading * Number of installed plugins * Anything else you think is useful -- 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-12672) Jobs take a long time to complete - get stuck sending success/failure email
[ https://issues.jenkins-ci.org/browse/JENKINS-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158756#comment-158756 ] SCM/JIRA link daemon commented on JENKINS-12672: Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceMailResolver.java http://jenkins-ci.org/commit/perforce-plugin/414cd9f0a6409b46eef58d1229953e5093daa940 Log: [JENKINS-12672] change method for getting list of projects for mail resolver user.getProjects() is very slow, since it scans every changelog of every project. Just go through all the projects instead. Jobs take a long time to complete - get stuck sending success/failure email --- Key: JENKINS-12672 URL: https://issues.jenkins-ci.org/browse/JENKINS-12672 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: Jenkins 1.450 Perforce plugin 1.3.7 Red Hat Enterprise Linux 4.5 Reporter: Ed Palazzo Assignee: Rob Petti We've noticed that sometimes our jobs get in a state where they're taking a long time to complete. Investigation reveals that the maven build has completing successfully, and it's stuck trying to send a success email. Left alone, the build will eventually complete but a 10 minute build may take several hours to succeed and blocks other jobs since the executors are busy. Manual monitoring and intervention is usually required to free up the jobs. Here's an example thread taken from a Jenkins thread dump that shows the stuck job. It appears to be processing the change list to retrieve the checkin user(s) that checked in code. Why is this taking so long? The exact stack changes with each thread dump, but it is consistent up to PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111). Executor #2 for master : executing markview-7.0.x_document-server #103 prio=10 tid=0x48865400 nid=0x5109 runnable [0x49bfa000] java.lang.Thread.State: RUNNABLE at java.util.ArrayList.size(ArrayList.java:177) at org.dom4j.tree.BackedList.init(BackedList.java:36) at org.dom4j.tree.AbstractBranch.createResultList(AbstractBranch.java:373) at org.dom4j.tree.AbstractElement.elements(AbstractElement.java:392) at org.dom4j.tree.AbstractElement.elementIterator(AbstractElement.java:428) at org.jaxen.dom4j.DocumentNavigator.getChildAxisIterator(DocumentNavigator.java:233) at org.jaxen.expr.iter.IterableChildAxis.namedAccessIterator(IterableChildAxis.java:98) at org.jaxen.expr.DefaultNameStep.evaluate(DefaultNameStep.java:180) at org.jaxen.expr.DefaultLocationPath.evaluate(DefaultLocationPath.java:140) at org.jaxen.expr.DefaultXPathExpr.asList(DefaultXPathExpr.java:102) at org.jaxen.BaseXPath.selectNodesForContext(BaseXPath.java:674) at org.jaxen.BaseXPath.selectNodes(BaseXPath.java:213) at org.jaxen.BaseXPath.selectSingleNode(BaseXPath.java:234) at org.dom4j.xpath.DefaultXPath.selectSingleNode(DefaultXPath.java:159) at org.dom4j.tree.AbstractNode.selectSingleNode(AbstractNode.java:185) at hudson.plugins.perforce.PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111) at hudson.plugins.perforce.PerforceChangeLogParser.parse(PerforceChangeLogParser.java:18) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:808) at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:782) at hudson.model.AbstractBuild.hasParticipant(AbstractBuild.java:356) at hudson.model.AbstractProject.hasParticipant(AbstractProject.java:1366) at hudson.model.User.getProjects(User.java:402) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:38) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675) at
