[JIRA] (JENKINS-35245) Pipeline SCM Step Plugin does not use the same git commit for the pipeline
Title: Message Title
Krzysztof Malinowski reopened an issue
Actually, I see this behavior buggy even with one checkout scm. Initial checkout done by the job itself (that takes Jenkinsfile) checks out different version than later build by checkout scm. Note that the job is set up to build any branch and a different branch is selected for actual build that it was for Jenkinsfile:
Jenkinsfile
node(buildServer) {
catchError {
stage ('checkout') {
checkout scm
}
}
Job output
Started by an SCM change
Started by an SCM change
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
...
Seen 81 remote branches
Checking out Revision 86cd5ee889a7802e13344fa214fbbf2ed22977d7 (origin/branch-a)
> git config core.sparsecheckout # timeout=10
> git checkout -f 86cd5ee889a7802e13344fa214fbbf2ed22977d7
First time build. Skipping changelog.
...
[Pipeline] node
Running on server in /dev/shm/jenkins/workspace/job
[Pipeline] {
[Pipeline] catchError
[Pipeline] {
[Pipeline] stage
[Pipeline] { (checkout)
[Pipeline] checkout
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
...
Seen 55 remote branches
Multiple candidate revisions
Checking out Revision b2ef6d5c88068da691260c4658e05b13f6d5c973 (origin/branch-b)
...
Jenkins / JENKINS-35245
Pipeline SCM Step Plugin does not use the same git commit for the pipeline
Change By:
Krzysztof Malinowski
Resolution:
Not A Defect
Status:
Resolved Reopened
[JIRA] (JENKINS-40352) Duplicate changesets in pipeline jobs
Title: Message Title Krzysztof Malinowski commented on JENKINS-40352 Re: Duplicate changesets in pipeline jobs I had this case when pipeline explicitly configured 'checkout git ...' instead of using 'checkout scm'. One changelog came from Git configuration in job (which is used to get Jenkinsfile) and the other came from explicitly configured scm in Jenkinsfile. Replacing 'checkout git ...' with 'checkout scm' in Jenkinsfile fixed the issue for me. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-28120) Jenkins core to require Java7
Title: Message Title Krzysztof Malinowski commented on JENKINS-28120 Re: Jenkins core to require Java7 We have some older slaves which run SunOS-5.9 for which Oracle does not provide Java7. Slave upgrade is not a solution either since there are some native legacy tools used in the build system which can only run on this machine. Does this mean I will have to stop upgrading Jenkins in order to have SunOS-5.9 slaves connected? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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-26445) Browser freezes when clicking more link on a job to see other builds
Title: Message Title Krzysztof Malinowski commented on JENKINS-26445 Re: Browser freezes when clicking more link on a job to see other builds Also have this problem when there is a long list of builds. Firefox developer tools console logs: Error: Script terminated by timeout at: Element.Methods.removeClassName@https://server:8080/static/63938483/scripts/prototype.js:2371:9 getElementOverflowParams@https://server:8080/static/63938483/scripts/hudson-behavior.js:1952:5 checkRowCellOverflows@https://server:8080/static/63938483/scripts/hudson-behavior.js:1693:37 checkAllRowCellOverflows@https://server:8080/static/63938483/scripts/hudson-behavior.js:1883:13 updateBuilds/.onSuccess@https://server:8080/static/63938483/scripts/hudson-behavior.js:1927:21 Ajax.Request.respondToReadyState@https://server:8080/static/63938483/scripts/prototype.js:1655:10 Ajax.Request.onStateChange@https://server:8080/static/63938483/scripts/prototype.js:1600:7 bind/@https://server:8080/static/63938483/scripts/prototype.js:414:14 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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-27948) Script timeout during start of configure a jenkins job
Title: Message Title Krzysztof Malinowski commented on JENKINS-27948 Re: Script timeout during start of configure a jenkins job Thank you, I could not find it However, I actually get both issues, JENKINS-26445 and JENKINS-27948, so I would suggest they might be related. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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-27948) Script timeout during start of configure a jenkins job
Title: Message Title Krzysztof Malinowski commented on JENKINS-27948 Re: Script timeout during start of configure a jenkins job I observe the same issue also in a different scenario: being in a job with a large list of completed builds, clicking on 'more...' at the bottom of the build list results in the same annoying popups with timeouts in prototype.js. Firefox developer tools console logs: Error: Script terminated by timeout at: Element.Methods.removeClassName@https://server:8080/static/63938483/scripts/prototype.js:2371:9 getElementOverflowParams@https://server:8080/static/63938483/scripts/hudson-behavior.js:1952:5 checkRowCellOverflows@https://server:8080/static/63938483/scripts/hudson-behavior.js:1693:37 checkAllRowCellOverflows@https://server:8080/static/63938483/scripts/hudson-behavior.js:1883:13 updateBuilds/.onSuccess@https://server:8080/static/63938483/scripts/hudson-behavior.js:1927:21 Ajax.Request.respondToReadyState@https://server:8080/static/63938483/scripts/prototype.js:1655:10 Ajax.Request.onStateChange@https://server:8080/static/63938483/scripts/prototype.js:1600:7 bind/@https://server:8080/static/63938483/scripts/prototype.js:414:14 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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-27188) BUILDID and BUILD_TAG from previous project
Krzysztof Malinowski commented on JENKINS-27188 BUILDID and BUILD_TAG from previous project I also experienced this (or related) issue with 1.602. PATH variable is being messed up from different jobs and/or nodes. Using EnvInject 1.91.1, downgraded to 1.90 didn't fix the issue. Reverting core to 1.598 fixes behavior immediately. 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-27188) BUILDID and BUILD_TAG from previous project
Krzysztof Malinowski commented on JENKINS-27188 BUILDID and BUILD_TAG from previous project Actually it's rather JENKINS-27197 which was duplicated to this issue. Moreover, you asked if it is still visible, so I reported. If you prefer another issue for this behavior, I can raise a new one. 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-25657) JUnit crashes during recording of test results in 1.580.1
Krzysztof Malinowski commented on JENKINS-25657 JUnit crashes during recording of test results in 1.580.1 Yes, it occurs still with 1.596 with matrix projects. JUnit in bundled version (1.2-beta-4), xUnit 1.93. Didn't occur with JUnit 1.1, but it's incompatible with current core. We don't have plain JUnit results, we use xUnit XSLT transform to parse results and JUnit plugin to get aggregation on Matrix parent level. 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] [clearcase-plugin] (JENKINS-9703) Find changes on a branch not working correctly with CC multisite
Krzysztof Malinowski commented on JENKINS-9703 Find changes on a branch not working correctly with CC multisite Actually this can be worked around using existing option of multi-site poll buffer. Unfortunately, even if the polling is done since previous build, it still will not be reliable. Consider such scenario: 9.00 AM - VOB sync is performed 9.05 AM - a change is submitted in remote site 9.10 AM - a build is done locally 9.15 AM - VOB sync is performed bringing changes from remote replica from 9.05 Now, even if the polling is run since last build (that is 9.10 AM), it will not include remote changes. I think that while multi-site poll buffer is a bit naive workaround, it works quite well until something smarter is invented. 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] [ssh-slaves-plugin] (JENKINS-8183) ssh connection failed when login banner is too long
Krzysztof Malinowski reopened JENKINS-8183 ssh connection failed when login banner is too long Hi, I have encountered the same issue, after our company changed initial banner string on sshd. It is indeed a line of banner string, terminated at 512. Simple check of banner shows: $ while read x; do echo $x | wc -c; done /usr/security/etc/banners/sshd 69 59 1 533 1 550 1 391 1 348 1 128 1 103 1 233 1 102 69 1 It fails on the first line that is longer than 512 lines. Change By: Krzysztof Malinowski (04/Dec/14 2:59 PM) Resolution: NotADefect Status: Resolved Reopened 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] [ssh-slaves-plugin] (JENKINS-8183) ssh connection failed when login banner is too long
Krzysztof Malinowski commented on JENKINS-8183 ssh connection failed when login banner is too long One more information: the SSH server responding is a Sun's implementation as of SunOS-5.10. Running a telnet connection to port 22 I get: all banner strings SSH-2.0-Sun_SSH_1.1.1 I have also looked into RFC referenced. I believe that the limit of 255 characters of the line is only referencing the SSH-* line, as it is stated before 'The server MAY send other lines of data before sending the version string' statement. I also believe that this RFC section does not put any restrictions on additional lines length or limit their amount. Thus I think also hard-coded check for 50 lines may not be appropriate. 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] [ssh-slaves-plugin] (JENKINS-8183) ssh connection failed when login banner is too long
Krzysztof Malinowski edited a comment on JENKINS-8183 ssh connection failed when login banner is too long Hi, I have encountered the same issue, after our company changed initial banner string on sshd. It is indeed a line of banner string, terminated at 512. Simple check of banner shows: $ while read x; do echo $x | wc -c; done /usr/security/etc/banners/sshd 69 59 1 533 1 550 1 391 1 348 1 128 1 103 1 233 1 102 69 1 It fails on the first line that is longer than 512 characters. 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] [clearcase-plugin] (JENKINS-25533) Restrict where this project can be run removed/disabled after Save/Apply of Job Configuration
Krzysztof Malinowski commented on JENKINS-25533 Restrict where this project can be run removed/disabled after Save/Apply of Job Configuration I am also observing this issue, using Jenkins 1.591 and Clearcase plugin. It's a major bug to me, as our projects are kept in Clearcase and any edit of job configuration removes target assignments. I appreciate long-term solution for core to be more resilient, but I would also make use of a short-term fix. 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] [disk-usage] (JENKINS-24627) ConcurrentModificationException with DiskUsage
Krzysztof Malinowski
created JENKINS-24627
ConcurrentModificationException with DiskUsage
Issue Type:
Bug
Assignee:
Lucie Votypkova
Components:
disk-usage
Created:
08/Sep/14 1:56 PM
Description:
It happens that opening job page hangs for a long time, while Jenkins log gets full of ConcurrentModificationException. Disabling disk-usage plugin eliminates the issue.
The exception starts in various ways, but always related to disk usage, i.e.:
WARNING: Caught exception evaluating: from.getSizeInString(from.getBuildsDiskUsage().get('all')) in /job/project/. Reason: java.util.ConcurrentModificationException
WARNING: Caught exception evaluating: from.getSizeInString(from.getJobRootDirDiskUsage()) in /view/view1/job/project/. Reason: java.util.ConcurrentModificationException
Full stack trace:
Sep 08, 2014 3:43:20 PM hudson.ExpressionFactory2$JexlExpression evaluate
WARNING: Caught exception evaluating: from.getSizeInString(from.getJobRootDirDiskUsage()) in /view/view1/job/project/. Reason: java.util.
ConcurrentModificationException
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
at hudson.plugins.disk_usage.ProjectDiskUsageAction.getBuildsDiskUsage(ProjectDiskUsageAction.java:232)
at hudson.plugins.disk_usage.ProjectDiskUsageAction.getBuildsDiskUsage(ProjectDiskUsageAction.java:203)
at hudson.plugins.disk_usage.ProjectDiskUsageAction.getJobRootDirDiskUsage(ProjectDiskUsageAction.java:134)
at sun.reflect.GeneratedMethodAccessor2745.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258)
at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.java:54)
at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:81)
at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74)
at org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:66)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:95)
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at
[JIRA] [jobgenerator] (JENKINS-22439) Conditional build steps are no longer resolved when generating jobs after core upgrade to 1.556
Krzysztof Malinowski commented on JENKINS-22439 Conditional build steps are no longer resolved when generating jobs after core upgrade to 1.556 I use Strings match, Regular _expression_ match and File exists conditions. It used to work OK, resolving strings and regex matches on generation level and keeping File exists condition in the generated job, which was exactly what I wanted. The log was like this: Before ... 16:30:21 [EnvInject] - Variables injected successfully. 16:30:21 [EnvInject] - Injecting contributions. 16:30:21 Building on master in workspace /jenkins/jenkins_home/jobs/generator-klocwork/workspace@6 16:30:21 16:30:21 Deleting project workspace... Strings match run condition: string 1=[https://server:8072], string 2=[] 16:30:21 Strings match run condition: string 1=[9.6.2], string 2=[] 16:30:21 Regular _expression_ run condition: _expression_=[^3[24]$], Label=[34] 16:30:21 Regular _expression_ run condition: _expression_=[^27|33$], Label=[34] 16:30:21 Regular _expression_ run condition: _expression_=[^14$], Label=[34] 16:30:22 Finished: SUCCESS Now, all condition steps are copied into generated job, none is evaluated on the generation level: After ... 10:40:46 [EnvInject] - Variables injected successfully. 10:40:46 [EnvInject] - Injecting contributions. 10:40:46 Building on master in workspace /jenkins/jenkins_home/jobs/generator-klocwork/workspace 10:40:46 10:40:47 Deleting project workspace... Finished: SUCCESS I am not entirely convinced it happened because of core upgrade as they were also some more plugins upgraded at the same time, but it's the only change that comes to my mind which may have affected behavior. Am I missing something here? BTW. Comparing now those two outputs I noticed two things: 1. The working version used workspace with @6 which I think is used only for concurrent runs of the same job. This has changed. 2. The build was always done on master. I don't know if it's important, but our master is configured to have 0 executors, so that all builds are always run on slaves. This may or may not have impact on this issue, but I thought it's good to mention it for reference. 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] [android-emulator] (JENKINS-22481) System images are not installed for Android versions specified as 'android-xx'
Krzysztof Malinowski created JENKINS-22481 System images are not installed for Android versions specified as android-xx Issue Type: Bug Assignee: Christopher Orr Components: android-emulator Created: 03/Apr/14 10:50 AM Description: When specifying 'Run emulator' with OS version given like 4.0.3, the plugin correctly detects and installs missing images, i.e.: $ /dev/shm/cp_hudson/tools/android-sdk/tools/android list target android The configured Android platform needs to be installed: android-15 $ /dev/shm/cp_hudson/tools/android-sdk/tools/android list target $ /dev/shm/cp_hudson/tools/android-sdk/tools/android list target android Installing the 'android-15,sysimg-15' SDK component(s)... $ /dev/shm/cp_hudson/tools/android-sdk/tools/android update sdk -u -a -t android-15,sysimg-15 ... android Using Android SDK: /dev/shm/cp_hudson/tools/android-sdk android Creating Android AVD: /dev/shm/cp_hudson/workspace/project/.android/avd/hudson_en-US_160_HVGA_android-15_armeabi-v7a.avd android /dev/shm/cp_hudson/tools/android-sdk/tools/android create avd -f -a -c 100M -s HVGA -n hudson_en-US_160_HVGA_android-15_armeabi-v7a -t android-15 --abi armeabi-v7a $ /dev/shm/cp_hudson/tools/android-sdk/platform-tools/adb start-server However, when OS is given like 'android-19', it doesn't seem to perform this check: $ /dev/shm/cp_hudson/tools/android-sdk/tools/android list target android Using Android SDK: /dev/shm/cp_hudson/tools/android-sdk android Creating Android AVD: /dev/shm/cp_hudson/workspace/project/.android/avd/hudson_en-US_160_HVGA_android-19_armeabi-v7a.avd android /dev/shm/cp_hudson/tools/android-sdk/tools/android create avd -f -a -c 100M -s HVGA -n hudson_en-US_160_HVGA_android-19_armeabi-v7a -t android-19 --abi armeabi-v7a Error: Invalid --abi armeabi-v7a for the selected target. android Could not create Android emulator: Failed to run AVD creation command It also doesn't help to provide OS version as 4.4.2: $ /dev/shm/cp_hudson/tools/android-sdk/tools/android list target android The configured Android platform needs to be installed: 4.4.2 android Using Android SDK: /dev/shm/cp_hudson/tools/android-sdk android Creating Android AVD: /dev/shm/cp_hudson/workspace/project/.android/avd/hudson_en-US_160_HVGA_4.4.2.avd android /dev/shm/cp_hudson/tools/android-sdk/tools/android create avd -f -a -c 100M -s HVGA -n hudson_en-US_160_HVGA_4.4.2 -t 4.4.2 android Failed to run AVD creation command Error: Target id is not valid. Use 'android list targets' to get the target ids. android Could not create Android emulator: Failed to run AVD creation command Environment: Jenkins 1.556 on RHEL5 x86_64, Android Emulator 2.10 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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] [jobgenerator] (JENKINS-22439) Conditional build steps are no longer resolved when generating jobs after core upgrade to 1.556
Krzysztof Malinowski created JENKINS-22439 Conditional build steps are no longer resolved when generating jobs after core upgrade to 1.556 Issue Type: Bug Assignee: Unassigned Components: jobgenerator Created: 31/Mar/14 7:23 PM Description: After core upgrade to 1.556 conditional build steps are no longer resolved when generating jobs. Instead all conditional build steps are now left in generated jobs, which works, but looks clumsy and is against documentation. Environment: Jenkins 1.556 on RHEL5 x86_64 Project: Jenkins Priority: Minor Reporter: Krzysztof Malinowski 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] [leastload] (JENKINS-20216) Jobs are scheduled on master which has 0 executors
Krzysztof Malinowski commented on JENKINS-20216 Jobs are scheduled on master which has 0 executors Hm... I am not really convinced by this explanation. I have master node configured with 0 executors, meaning that this node is not even listed on the node list and no jobs should be run there. It also did not happen until leastload plugin was installed. Now it happens that such flyweight task is scheduled on master, and master node then shows up in the node list running the task. Can the plugin you mentioned be used to configure master node? Or can it only be used for slaves? 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] [clearcase] (JENKINS-12911) Clearecase Plugin Not Detecting Changes
Krzysztof Malinowski commented on JENKINS-12911 Clearecase Plugin Not Detecting Changes SCM polling should not be run on master. First of all, Clearcase view or its config spec can be invalid on master due to different regions/VOB tags. In situation when you have Unix/Windows clients it's quite frequent to have VOBs registered at different VOB tags, since Windows does not allow hierarchical VOB tags (like /vob/vob1). Therefore if the build should be run on Windows, it cannot be polled on Unix since config spec may be invalid (and vice versa). As a matter of the fact master node is not even required to have Clearcase installed. My Jenkins configuration has a master node with no executors, it only connects to slaves to run the builds. Polling at master would have no sense in this situation. 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] [platformlabeler] (JENKINS-17615) Platform labels disappear from SSH slave node
Krzysztof Malinowski created JENKINS-17615 Platform labels disappear from SSH slave node Issue Type: Bug Affects Versions: current Assignee: lifeless Components: platformlabeler Created: 15/Apr/13 2:34 PM Description: I have 4 similar SSH slave nodes configured. After upgrading to Jenkins 1.510 one of them keeps losing platform labels. In effect all jobs tied to a platform label skip this node. The node has one manually assigned label. When the issue happens only this one label stays on the node, but all automatically assigned platform labels disappear. To recover from such situation I need: Disconnect the node and relaunch it, Enter node configuration and press Save button. After first step (disconnect/relaunch) platform labels do show up, but Jenkins still does not see those labels (reporting no executors with required label available). I need to perform second step (Configure/Save) to make Jenkins actually refresh its labels knowledge. This is an issue I already reported, just in this case it's always reproducible. Anyway, this solution is not permanent, because after some time platform labels get dropped again and I need to repeat the steps above. I wasn't observing this issue before upgrade to 1.510. Environment: Jenkins 1.510 on RHEL5 x86_64 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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] [platformlabeler] (JENKINS-17615) Platform labels disappear from SSH slave node
Krzysztof Malinowski updated JENKINS-17615 Platform labels disappear from SSH slave node Change By: Krzysztof Malinowski (15/Apr/13 2:36 PM) Description: Ihave4similarSSHslavenodesconfigured.AfterupgradingtoJenkins1.510oneofthemkeepslosingplatformlabels.Ineffectalljobstiedtoaplatformlabelskipthisnode.Thenodehasonemanuallyassignedlabel.Whentheissuehappensonlythisonelabelstaysonthenode,butallautomaticallyassignedplatformlabelsdisappear.TorecoverfromsuchsituationIneed:-Disconnectthenodeandrelaunchit,-EnternodeconfigurationandpressSavebutton.Afterfirststep(disconnect/relaunch)platformlabelsdoshowup,butJenkinsstilldoesnotseethoselabels(reportingnoexecutorswithrequiredlabelavailable).Ineedtoperformsecondstep(Configure/Save)tomakeJenkinsactuallyrefreshitslabelsknowledge.ThisisanissueIalreadyreported (JENKINS-9586) ,justinthiscaseitsalwaysreproducible.Anyway,thissolutionisnotpermanent,becauseaftersometimeplatformlabelsgetdroppedagainandIneedtorepeatthestepsabove.Iwasntobservingthisissuebeforeupgradeto1.510. 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] [core] (JENKINS-17617) SECURITY: It's possible to set SSH key for another user
Krzysztof Malinowski created JENKINS-17617 SECURITY: Its possible to set SSH key for another user Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 15/Apr/13 3:00 PM Description: It is possible to enter another user configuration, using URL like http://jenkins-instance/user/username/configure and change (or assign) SSH key for this user. It is now possible to authenticate through CLI as this user and initiate actions on behalf of another user, probably with higher privileges. Additionally, since not many users are aware of configuration section per user, this change may get unnoticed for quite a long time. Environment: Jenkins 1.510 on RHEL5 x86_64 Project: Jenkins Priority: Critical Reporter: Krzysztof Malinowski 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-17266) Build now link from context menu no longer works for parameterized builds
Krzysztof Malinowski created JENKINS-17266 Build now link from context menu no longer works for parameterized builds Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 19/Mar/13 10:20 AM Description: When trying to run 'Build now' command from context menu (either from breadcrumbs bar or from the dashboard view) for a parameterized job, there is absolutely no effect. Inspecting HTTP requests shows that server responds with HTTP 400 Bad Request for such command. I suggest to redirect to parameters page, as it worked before requirement for POST actions to build was introduced. Environment: Jenkins 1.506 on RHEL 5 x86_64 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-17064) Unable to edit some build definitions
Krzysztof Malinowski commented on JENKINS-17064 Unable to edit some build definitions Same issue here. Running Jenkins 1.504 on RHEL5 x86_64, with email-ext 1.27. It seems however that it is only triggered in Matrix builds and the stacktrace is a little bit different: Content Token Reference Help for feature: Content Token Reference Trigger for matrix projects Status Code: 500 Exception: org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.504.jar!/lib/form/hetero-list.jelly:119:94: st:include org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.504.jar!/lib/form/entry.jelly:73:23: d:invokeBody Cannot get property 'description' on null object Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.504.jar!/lib/form/hetero-list.jelly:119:94: st:include org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.504.jar!/lib/form/entry.jelly:73:23: d:invokeBody Cannot get property 'description' on null object at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:50) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:102) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:272) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:175) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:65) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82) at
[JIRA] (JENKINS-16551) NPE during copy project
Krzysztof Malinowski commented on JENKINS-16551 NPE during copy project I could if I had it installed I have never installed chuck norris plugin. 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-16551) NPE during copy project
Krzysztof Malinowski created JENKINS-16551 NPE during copy project Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 30/Jan/13 1:28 PM Description: Trying to copy Maven project to a new one, upon pressing OK I get: Status Code: 500 Exception: java.lang.NullPointerException Stacktrace: javax.servlet.ServletException: java.lang.NullPointerException at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:615) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:50) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:272) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:175) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:64) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:140) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NullPointerException at hudson.model.AbstractProject.getLastBuild(AbstractProject.java:1021) at hudson.maven.AbstractMavenProject.createTransientActions(AbstractMavenProject.java:184) at
[JIRA] (JENKINS-16547) Error code 500 when session times out
Krzysztof Malinowski created JENKINS-16547 Error code 500 when session times out Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 30/Jan/13 12:10 PM Description: When the session times out, user is no longer logged in. Trying to reach any page that is unavailable for anonymous users (even a simple refresh on the page) result in server error: Status Code: 500 Exception: org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.500.jar!/hudson/model/View/index.jelly:44:43: st:include Cannot invoke method isEmpty() on null object Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.500.jar!/hudson/model/View/index.jelly:44:43: st:include Cannot invoke method isEmpty() on null object at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:562) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:50) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:272) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:175) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:64) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at
[JIRA] (JENKINS-9586) Sometimes after Jenkins restart platform labels are not available
Krzysztof Malinowski commented on JENKINS-9586 Sometimes after Jenkins restart platform labels are not available It is. I just encountered it again yesterday starting up Jenkins 1.499. 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-16393) Unable to call join build failures
Krzysztof Malinowski created JENKINS-16393 Unable to call join build failures Issue Type: Bug Assignee: Unassigned Components: core Created: 17/Jan/13 2:42 PM Description: It happens that builds fail with something like: FATAL: Unable to call join. Invalid object ID 1583 java.lang.IllegalStateException: Unable to call join. Invalid object ID 1583 at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:269) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:256) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) 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:662) This reduces chance to get successful matrix build. In this particular instance 4 out of 10 configurations in matrix build failed with this stacktrace upon requesting changes from scm. Environment: Jenkins 1.498 on RHEL 5 x86_64 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-16287) Race condition in 'build' CLI command
Krzysztof Malinowski created JENKINS-16287 Race condition in build CLI command Issue Type: Bug Assignee: Unassigned Components: cli Created: 09/Jan/13 8:50 AM Description: I started a build through jenkins-cli.jar with option to show console and wait for start. It waited to start as long as the build was in queue, but when the build started to build, jenkins-cli exits with exception that log was not found. It seems to me like a race condition between build start, log creation and checking for log in jenkins-cli. $ java -jar ~/jenkins-cli.jar build project -p build=value -s -v -w Started project #188 java.io.FileNotFoundException: /jenkins/jenkins_home/jobs/project/builds/2013-01-09_09-43-12/log (No such file or directory) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.init(RandomAccessFile.java:216) at org.kohsuke.stapler.framework.io.LargeText$FileSession.init(LargeText.java:397) at org.kohsuke.stapler.framework.io.LargeText$2.open(LargeText.java:120) at org.kohsuke.stapler.framework.io.LargeText.writeLogTo(LargeText.java:210) at hudson.console.AnnotatedLargeText.writeLogTo(AnnotatedLargeText.java:151) at hudson.model.Run.writeWholeLogTo(Run.java:1253) at hudson.cli.BuildCommand.run(BuildCommand.java:150) at hudson.cli.CLICommand.main(CLICommand.java:229) at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92) 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 hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:275) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:256) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63) at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95) 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:662) Environment: Jenkins 1.498 on RHEL 5 x86_64 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498
Krzysztof Malinowski commented on JENKINS-16273 Slaves cannot connect to master through JNLP after upgrading to 1.498 Same issue here. Reading through the comments above it made me think: would it be possible to make when jnlp is first started through a web browser to save this jnlp to local Jenkins directory and automatically configure service to use this cached copy instead of requesting it from the server? This would make setting up slaves automatic again without altering security fix. 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-16239) NPE in getRootDir
Krzysztof Malinowski commented on JENKINS-16239 NPE in getRootDir I did upgrade from 1.495 to 1.496 and EnvInject from 1.75 to 1.78. Reverted both core and envinject back to 1.495 and 1.75 respectively, but the issue still exists. It is possible that issue has been existing for some time now only I discovered it yesterday. 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-16239) NPE in getRootDir
Krzysztof Malinowski commented on JENKINS-16239 NPE in getRootDir I also discovered that this error is being reported permanently, upon navigating Jenkins UI. There are reported multiple times at once. Here is the more complete stack trace: java.lang.NullPointerException at hudson.model.Run.getRootDir(Run.java:927) at org.jenkinsci.lib.envinject.EnvInjectAction.readResolve(EnvInjectAction.java:86) at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callReadResolve(SerializationMethodInvoker.java:46) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:222) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:332) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:274) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:221) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:332) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:274) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:221) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at
[JIRA] (JENKINS-16239) NPE in getRootDir
Krzysztof Malinowski created JENKINS-16239 NPE in getRootDir Issue Type: Bug Assignee: Gregory Boissinot Components: core, envinject Created: 02/Jan/13 1:50 PM Description: Upon startup projects are being loaded and for some (matrix) projects the log contains: java.lang.NullPointerException at hudson.model.Run.getRootDir(Run.java:927) at org.jenkinsci.lib.envinject.EnvInjectAction.readResolve(EnvInjectAction.java:86) Environment: Jenkins 1.496 on RHEL5 x86_64, EnvInject 1.78 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15796) NoClassDefFoundError in monitoring Windows slave
Krzysztof Malinowski created JENKINS-15796 NoClassDefFoundError in monitoring Windows slave Issue Type: Bug Assignee: Unassigned Components: core Created: 10/Nov/12 9:46 PM Description: Upon startup there is a bunch of exceptions in log: Nov 10, 2012 10:37:25 PM hudson.node_monitors.AbstractNodeMonitorDescriptor$Record run WARNING: Failed to monitor windowsxp-slave for Free Swap Space java.io.IOException: Remote call on akm022-06 failed at hudson.remoting.Channel.call(Channel.java:673) at hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:83) at hudson.node_monitors.SwapSpaceMonitor$1.monitor(SwapSpaceMonitor.java:81) at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:219) Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jvnet.hudson.Windows$MEMORYSTATUSEX at org.jvnet.hudson.Windows.monitor(Windows.java:40) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:113) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:99) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source) It happens for both Windows 7 and Windows XP slaves. Environment: Jenkins 1.489 on RHEL 5 x86_64 with Windows 7/Windows XP slaves Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15718) Failed to record SCM polling (again) while polling for SCM changes (Clearcase, Mercurial...)
Krzysztof Malinowski commented on JENKINS-15718 Failed to record SCM polling (again) while polling for SCM changes (Clearcase, Mercurial...) Confirm, same issue with 1.489 and Clearcase 1.3.7. With such bug I see Jenkins 1.489 as totally useless. 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-15335) Jenkins briefly displays build queue and then it disappears until the page is reloaded
Krzysztof Malinowski commented on JENKINS-15335 Jenkins briefly displays build queue and then it disappears until the page is reloaded I'm not sure this is the same issue. Original issue was about build queue (pending jobs) while vijay's issue is about builds and workspace in the job itself. I have also observed it with 1.487 and problem disappeared after reverting to 1.486. I believe it should be reported as a new issue. 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-15719) Builds and workspace disappear for jobs created after upgrade to 1.487
Krzysztof Malinowski created JENKINS-15719 Builds and workspace disappear for jobs created after upgrade to 1.487 Issue Type: Bug Assignee: Unassigned Components: core Created: 05/Nov/12 11:34 AM Description: Recreated from comment in JENKINS-15335: Every new job created post 1.487 have their builds and workspace disappearing on the UI. Reverted to release 1.486 and all builds and workspace are visible. I have observed the same issue for a job that was created as well as for the job being renamed after upgrade. Again, reverting to 1.486 caused the issue to go away. Note that all builds (run both before upgrade and after upgrade) are recorded in JENKINS_HOME and showed up after reverting to 1.486. Jobs that were not renamed or created after upgrade were not affected. Environment: Jenkins 1.487 on RHEL5 x86_64 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15679) NPE when expanding more entries in build history
Krzysztof Malinowski created JENKINS-15679 NPE when expanding more entries in build history Issue Type: Bug Assignee: Unassigned Components: core Created: 31/Oct/12 10:19 AM Description: When clicked "more..." in the build history panel on the job page, it showed the following: Exception: org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.486.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: i:formatDate java.lang.NullPointerException Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/jenkins/jenkins_home/war/WEB-INF/lib/jenkins-core-1.486.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: i:formatDate java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:50) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:102) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:91) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:168) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:272) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:64) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at
[JIRA] (JENKINS-10818) Clearcase plugin does not compile on JDK 7
Krzysztof Malinowski reopened JENKINS-10818 Clearcase plugin does not compile on JDK 7 It's not been integrated yet in trunk, awaiting maintainer's acceptance. Change By: Krzysztof Malinowski (29/Oct/12 9:53 AM) Resolution: Fixed Status: Resolved Reopened 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-15631) When custom tool installation is on SCM checkout fails
Krzysztof Malinowski created JENKINS-15631 When custom tool installation is on SCM checkout fails Issue Type: Bug Assignee: recampbell Components: customtools-plugin, envinject Created: 25/Oct/12 3:48 PM Description: When enabled custom tool installation on a job running on Windows slave Clearcase checkout fails due to (most probably) missing 'cleartool' on PATH. It seems that custom tool path injection somehow affects PATH set from envinject plugin (maybe also use of PATH vs Path?) Log from failing build 16:46:08 Started by user user1 16:46:10 Bullshtml 1.5 is installed at D:\Jenkins\tools\Custom_tool\Bullshtml_1.5\bullshtml 16:46:10 EnvInject - Loading node environment variables. 16:46:10 EnvInject - Preparing an environment for the build. 16:46:10 EnvInject - Keeping Jenkins system variables. 16:46:10 EnvInject - Keeping Jenkins build variables. 16:46:10 EnvInject - Adding build parameters as variables. 16:46:10 EnvInject - Injecting as environment variables the properties content 16:46:10 include_dir=//server/path/to/include/dir 16:46:10 16:46:10 EnvInject - Variables injected successfully. 16:46:10 EnvInject - Injecting contributions. 16:46:10 Building remotely on windows-slave in workspace D:\Jenkins\workspace\job 16:46:10 16:46:10 Deleting project workspace... done 16:46:10 16:46:10 view $ cleartool lsview -cview -s 16:46:10 job $ cleartool lsview viewname 16:46:10 FATAL: Base ClearCase failed. exit code=-1073741515 16:46:10 job $ cleartool mkview -snapshot -tag viewname -vws \\WINDOWS-SLAVE\Viewstore\viewname.vws view 16:46:11 FATAL: Base ClearCase failed. exit code=-1073741515 16:46:11 java.io.IOException: cleartool did not return the expected exit code. Command line="mkview -snapshot -tag viewname -vws \\WINDOWS-SLAVE\Viewstore\viewname.vws view", actual exit code=-1073741515 Environment: Jenkins 1.486 on RHEL5 x86_64, Windows XP slave, Custom tools 0.1, EnvInject 1.72 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15545) NPE in BuildTrigger
Krzysztof Malinowski created JENKINS-15545 NPE in BuildTrigger Issue Type: Bug Assignee: Unassigned Components: core Created: 17/Oct/12 9:01 AM Description: Oct 17, 2012 10:39:23 AM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: descriptor.showEvenIfUnstableOption(targetType). Reason: java.lang.NullPointerException java.lang.NullPointerException at hudson.tasks.BuildTrigger$DescriptorImpl.showEvenIfUnstableOption(BuildTrigger.java:315) 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 org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateAsBoolean(ExpressionSupport.java:71) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:97) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:41) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53) at hudson.widgets.RenderOnDemandClosure$1.generateResponse(RenderOnDemandClosure.java:91) at org.kohsuke.stapler.HttpResponseRenderer$Default.handleHttpResponse(HttpResponseRenderer.java:104) at org.kohsuke.stapler.HttpResponseRenderer$Default.generateResponse(HttpResponseRenderer.java:62) at org.kohsuke.stapler.Function.renderResponse(Function.java:103) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:92) at org.kohsuke.stapler.MetaClass$_javascript_ProxyMethodDispatcher.doDispatch(MetaClass.java:439) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at
[JIRA] (JENKINS-15507) Environment variables are not injected in parent matrix job
Krzysztof Malinowski created JENKINS-15507 Environment variables are not injected in parent matrix job Issue Type: Bug Assignee: Gregory Boissinot Components: envinject Created: 12/Oct/12 9:43 AM Description: When I choose to prepare environment for the run and provide properties content, these are not injected in matrix parent project. This behavior causes SCM checkout to fail, since variables are required in Clearcase config spec. Environment: Jenkins 1.485 on RHEL5 x86_64, envinject 1.72 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15403) Jenkins slave Windows service does not reconnect on master failure
Krzysztof Malinowski created JENKINS-15403 Jenkins slave Windows service does not reconnect on master failure Issue Type: Bug Assignee: Unassigned Components: core Created: 04/Oct/12 3:26 PM Description: I have set up Jenkins slave Windows service so that it is restarted by system on failure. It works OK if slave fails for whatever reasons. Unfortunately recently master keeps failing due to out of memory problems and after master reboot some Windows slave do not reconnect. Service has to be restarted in order to connect slave again. jenkins-slave.err.log Oct 02, 2012 3:59:10 PM hudson.remoting.jnlp.Main$CuiListener init INFO: Hudson agent is running in headless mode. Oct 02, 2012 3:59:10 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among http://server:8080/ Oct 02, 2012 3:59:10 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to server:21234 Oct 02, 2012 3:59:10 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Oct 02, 2012 3:59:11 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connected Oct 03, 2012 8:11:21 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated Oct 03, 2012 8:12:22 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among http://server:8080/ Oct 03, 2012 8:12:22 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to server:21234 Oct 03, 2012 8:12:22 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Oct 03, 2012 8:12:22 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Connected Oct 03, 2012 8:15:19 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated Oct 03, 2012 8:15:59 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among http://server:8080/ Oct 03, 2012 8:15:59 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to server:21234 Oct 03, 2012 8:15:59 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Oct 03, 2012 8:15:59 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Connected Oct 03, 2012 9:44:59 PM hudson.slaves.ChannelPinger$1 onDead INFO: Ping failed. Terminating the channel. java.util.concurrent.TimeoutException: Ping started on 1349293259718 hasn't completed at 1349293499718 at hudson.remoting.PingThread.ping(PingThread.java:120) at hudson.remoting.PingThread.run(PingThread.java:81) Oct 03, 2012 9:44:59 PM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.net.SocketException: socket closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Oct 03, 2012 9:44:59 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated Oct 04, 2012 4:20:07 PM hudson.remoting.jnlp.Main$CuiListener init INFO: Hudson agent is running in headless mode. Oct 04, 2012 4:20:07 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among http://server:8080/ Oct 04, 2012 4:20:07 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to server:21234 Oct 04, 2012 4:20:07 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Oct 04, 2012 4:20:07 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connected 2012-10-02 15:59:10 - Starting C:\Program Files\Java\jre7\bin\java.exe -Xrs -jar "C:\Jenkins\slave.jar" -jnlpUrl http://server:8080/computer/slave-1/slave-agent.jnlp 2012-10-02
[JIRA] (JENKINS-15403) Jenkins slave Windows service does not reconnect on master failure
Krzysztof Malinowski
updated JENKINS-15403
Jenkins slave Windows service does not reconnect on master failure
Change By:
Krzysztof Malinowski
(04/Oct/12 3:27 PM)
Description:
IhavesetupJenkinsslaveWindowsservicesothatitisrestartedbysystemonfailure.ItworksOKifslavefailsforwhateverreasons.UnfortunatelyrecentlymasterkeepsfailingduetooutofmemoryproblemsandaftermasterrebootsomeWindowsslavedonotreconnect.Servicehastoberestartedinordertoconnectslaveagain.{panel:title=jenkins-slave.err.log}Oct02,20123:59:10PMhudson.remoting.jnlp.Main$CuiListenerinitINFO:Hudsonagentisrunninginheadlessmode.Oct02,20123:59:10PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Locatingserveramong[http://server:8080/]Oct02,20123:59:10PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Connectingtoserver:21234Oct02,20123:59:10PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:HandshakingOct02,20123:59:11PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:ConnectedOct03,20128:11:21AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:TerminatedOct03,20128:12:22AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Locatingserveramong[http://server:8080/]Oct03,20128:12:22AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Connectingtoserver:21234Oct03,20128:12:22AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:HandshakingOct03,20128:12:22AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:ConnectedOct03,20128:15:19AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:TerminatedOct03,20128:15:59AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Locatingserveramong[http://server:8080/]Oct03,20128:15:59AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Connectingtoserver:21234Oct03,20128:15:59AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:HandshakingOct03,20128:15:59AMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:ConnectedOct03,20129:44:59PMhudson.slaves.ChannelPinger$1onDeadINFO:Pingfailed.Terminatingthechannel.java.util.concurrent.TimeoutException:Pingstartedon1349293259718hasntcompletedat1349293499718 athudson.remoting.PingThread.ping(PingThread.java:120) athudson.remoting.PingThread.run(PingThread.java:81)Oct03,20129:44:59PMhudson.remoting.SynchronousCommandTransport$ReaderThreadrunSEVERE:I/Oerrorinchannelchanneljava.net.SocketException:socketclosed atjava.net.SocketInputStream.socketRead0(NativeMethod) atjava.net.SocketInputStream.read(UnknownSource) atjava.net.SocketInputStream.read(UnknownSource) atjava.io.BufferedInputStream.fill(UnknownSource) atjava.io.BufferedInputStream.read(UnknownSource) atjava.io.ObjectInputStream$PeekInputStream.peek(UnknownSource) atjava.io.ObjectInputStream$BlockDataInputStream.peek(UnknownSource) atjava.io.ObjectInputStream$BlockDataInputStream.peekByte(UnknownSource) atjava.io.ObjectInputStream.readObject0(UnknownSource) atjava.io.ObjectInputStream.readObject(UnknownSource) athudson.remoting.Command.readFrom(Command.java:90) athudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) athudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)Oct03,20129:44:59PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:TerminatedOct04,20124:20:07PMhudson.remoting.jnlp.Main$CuiListenerinitINFO:Hudsonagentisrunninginheadlessmode.Oct04,20124:20:07PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Locatingserveramong[http://server:8080/]Oct04,20124:20:07PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Connectingtoserver:21234Oct04,20124:20:07PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:HandshakingOct04,20124:20:07PMhudson.remoting.jnlp.Main$CuiListenerstatusINFO:Connected{panel}{panel:
title=
jenkins-slave.wrapper.log}2012-10-0215:59:10-StartingC:\ProgramFiles\Java\jre7\bin\java.exe-Xrs-jarC:\Jenkins\slave.jar-jnlpUrlhttp://server:8080/computer/slave-1/slave-agent.jnlp2012-10-0215:59:10-Started56802012-10-0416:20:05-Stoppingjenkinsslave-C__Jenkins2012-10-0416:20:05-ProcessKill56802012-10-0416:20:05-Finishedjenkinsslave-C__Jenkins2012-10-0416:20:06-StartingC:\ProgramFiles\Java\jre7\bin\java.exe-Xrs-jarC:\Jenkins\slave.jar-jnlpUrlhttp://server:8080/computer/slave-1/slave-agent.jnlp2012-10-0416:20:06-Started6464{panel}Notethatbeforeexceptionslaveitselfreconnectedmanytimestomaster,butafterexceptionitdidnotrecoveruntilservicewasrestarted.
[JIRA] (JENKINS-15335) Jenkins briefly displays build queue and then it disappears until the page is reloaded
Krzysztof Malinowski commented on JENKINS-15335 Jenkins briefly displays build queue and then it disappears until the page is reloaded I am also affected by the issue. Voting for fix in the very near future. 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-15355) AdjunctManager: exception upon startup
Krzysztof Malinowski created JENKINS-15355 AdjunctManager: exception upon startup Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 28/Sep/12 2:45 PM Description: Upon startup there are few instances of exception logged: Sep 28, 2012 4:41:33 PM org.kohsuke.stapler.jelly.AdjunctTag doTag WARNING: AdjunctManager is not installed for this application. Skipping adjunct tags java.lang.Exception at org.kohsuke.stapler.jelly.AdjunctTag.doTag(AdjunctTag.java:74) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53) at org.kohsuke.stapler.jelly.JellyRequestDispatcher.forward(JellyRequestDispatcher.java:55) at hudson.util.HudsonIsLoading.doDynamic(HudsonIsLoading.java:45) 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 org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:363) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:162) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at
[JIRA] (JENKINS-15356) NPE caused executor thread death
Krzysztof Malinowski created JENKINS-15356 NPE caused executor thread death Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 28/Sep/12 2:52 PM Description: The following information was available on a "Thread has died" page: java.lang.NullPointerException at hudson.matrix.MatrixConfiguration.newBuild(MatrixConfiguration.java:218) at hudson.matrix.MatrixConfiguration.newBuild(MatrixConfiguration.java:64) at hudson.model.AbstractProject.createExecutable(AbstractProject.java:1197) at hudson.model.AbstractProject.createExecutable(AbstractProject.java:136) at hudson.model.Executor.run(Executor.java:211) Environment: Jenkins 1.480 on RHEL 5 x86_64 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15332) NPE in Klocwork KloBuildAction
Krzysztof Malinowski created JENKINS-15332 NPE in Klocwork KloBuildAction Issue Type: Bug Affects Versions: current Assignee: Gregory Boissinot Components: klocwork Created: 27/Sep/12 10:37 AM Description: Sep 27, 2012 12:32:48 PM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.isSummary(). Reason: java.lang.NullPointerException java.lang.NullPointerException at com.thalesgroup.hudson.plugins.klocwork.KloBuildAction.isSummary(KloBuildAction.java:102) Environment: Jenkins 1.483 on RHEL 5 x86_64, Klocwork plugin 1.12 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15159) OutOfMemoryException on launching slave
Krzysztof Malinowski created JENKINS-15159 OutOfMemoryException on launching slave Issue Type: Bug Assignee: Unassigned Components: core Created: 13/Sep/12 8:09 PM Description: OutOfMemoryException during slave connection. When connecting slave through SSH: 09/13/12 21:56:30 SSH Checking java version of java 09/13/12 21:56:30 SSH java -version returned 1.6.0_24. 09/13/12 21:56:30 SSH Starting sftp client. 09/13/12 21:56:30 SSH Copying latest slave.jar... 09/13/12 21:56:30 SSH Copied 278,201 bytes. 09/13/12 21:56:30 SSH Starting slave process: cd '/dev/shm/cp_hudson' java -jar slave.jar ===JENKINS REMOTING CAPACITY===channel started Slave.jar version: 2.17 This is a Unix slave ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins. java.lang.OutOfMemoryError: getNewTla at java.util.HashMap.addEntry(HashMap.java:937) at java.util.HashMap.put(HashMap.java:477) at java.util.HashSet.add(HashSet.java:200) at java.io.ObjectStreamClass$FieldReflector.init(ObjectStreamClass.java:1852) at java.io.ObjectStreamClass.getReflector(Unknown Source) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:459) at java.io.ObjectStreamClass.lookup0(ObjectStreamClass.java:308) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java) at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:545) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) ERROR: Connection terminated 09/13/12 21:56:32 SSH Connection closed. java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) ERROR: 09/13/12 21:56:32 slave agent was terminated java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) When accepting connection from JNLP client: INFO: Accepted connection #10 from /xx.xx.xx.82:2652 Exception in thread "TCP slave agent connection handler #10 with /xx.xx.xx.82:2652" java.lang.OutOfMemoryError: getNewTla at java.util.HashMap.addEntry(HashMap.java:937) at java.util.HashMap.put(HashMap.java:477) at java.util.HashSet.add(HashSet.java:200) at java.io.ObjectStreamClass$FieldReflector.init(ObjectStreamClass.java:1852) at java.io.ObjectStreamClass.getReflector(Unknown Source) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:459) at java.io.ObjectStreamClass.lookup0(ObjectStreamClass.java:308) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java) at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:545) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) at
[JIRA] (JENKINS-14623) EnvInject ignores changes in system configuration
Krzysztof Malinowski commented on JENKINS-14623 EnvInject ignores changes in system configuration If this is blocked by Jenkins core, I think it would be better to retarget this issue to core. Restarting Jenkins instance is an expensive operation and until new configuration is applied some of the builds are failing. I find such behavior unacceptable. 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-14569) PATH is not being injected correctly
Krzysztof Malinowski commented on JENKINS-14569 PATH is not being injected correctly I have verified on a clean Jenkins installation that it works correctly indeed. It seems that there is some conflict with "Hudson setenv plugin". It was installed so long ago that I didn't remember it was a plugin; thought that setting environment was a Jenkins built-in. Clean Jenkins installation convinced me it's not. Anyway, seems not to be a problem. Rather my configuration issue. 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-14569) PATH is not being injected correctly
Krzysztof Malinowski stopped work on JENKINS-14569 PATH is not being injected correctly Change By: Krzysztof Malinowski (31/Aug/12 9:11 AM) Status: InProgress Open 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-14569) PATH is not being injected correctly
Krzysztof Malinowski closed JENKINS-14569 as Not A Defect PATH is not being injected correctly Turned out it was a configuration issue. Change By: Krzysztof Malinowski (31/Aug/12 9:12 AM) Status: Open Closed Resolution: NotADefect 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-12911) Clearecase Plugin Not Detecting Changes
Krzysztof Malinowski commented on JENKINS-12911 Clearecase Plugin Not Detecting Changes Could you please show your clearcase scm configuration? 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-14623) EnvInject ignores changes in system configuration
Krzysztof Malinowski commented on JENKINS-14623 EnvInject ignores changes in system configuration I eventually did, but I find this behavior unfriendly and not intuitive. In this particular situation I could not restart Jenkins at once, since there were other jobs building, some of them run for many hours. So in case I could not restart Jenkins instance, I also could not build another job which relied on global configuration. Built-in variable setting does not work that way and does not require Jenkins restart after changing global configuration. 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-14569) PATH is not being injected correctly
Krzysztof Malinowski
commented on JENKINS-14569
PATH is not being injected correctly
No.
At first, I don't understand why EnvInject distinguishes PATH from Path on Windows, when standard Jenkins variable setup implementation does not behave this way.
Secondly, the issue is also about installing EnvInject makes standard environment setup working incorrectly. I used to have jobs which added to PATH within standard 'set environment variables' and these are no longer applied, even though I have not enabled any EnvInject option in the project. It seems that installing EnvInject itself breaks the way Jenkins handles environment variables for the build (or at least PATH variable). This is true for Unix-based build as well.
To reproduce the issue:
on the node set environment variable PATH
create a new free style build and tie it on this node
in the job check 'set environment variable' and add something to the PATH
int the build step use shell step and run 'echo ${PATH}'
notice that PATH does not contain modifications from standard settings
While I understand that this field is not part of EnvInject setup, I find it breaking since installing EnvInject is enough to break jobs that are set up like this (the jobs do not even need to have EnvInject configured).
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-14622) Windows slave service credentials are not updated
Krzysztof Malinowski created JENKINS-14622 Windows slave service credentials are not updated Issue Type: Bug Assignee: Unassigned Components: core Created: 30/Jul/12 9:04 AM Description: I have a Windows slave set up to be run by WMI. It uses the same credentials to start the service as they are used to connect to host. Some time ago password has expired so I updated connection credentials in the slave setup. Jenkins did connect however it could not start the service. Investigating slave's Event Viewer showed that the service could not log on, since apparently its password has not been updated. I recommend that service's credentials should be updated on every slave connection to avoid such situations. Environment: Jenkins 1.475 on RHEL5 x86_64, Windows XP slave Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-14621) When connecting Windows slave error is not seen in the log
Krzysztof Malinowski created JENKINS-14621 When connecting Windows slave error is not seen in the log Issue Type: Improvement Assignee: Unassigned Components: core Created: 30/Jul/12 8:59 AM Description: I try to connect Windows slave through WMI infrastructure. The log goes up to this: Connecting to computer-name Checking if Java exists java full version "1.7.0_05-b05" Copying jenkins-slave.xml Copying slave.jar Starting the service The spinning wheel goes on and on. When I go back to list of nodes the starting node has a red X, so I go in and see that launching the slave has failed. When I see the log it still shows up the same "Starting the service" message. It would be good to log some message at this node startup log that the startup has failed, otherwise one may waste quite a long time waiting for the service. Environment: Jenkins 1.475 on RHEL5 x86_64, Windows XP slave Project: Jenkins Priority: Minor Reporter: Krzysztof Malinowski 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-14623) EnvInject ignores changes in system configuration
Krzysztof Malinowski created JENKINS-14623 EnvInject ignores changes in system configuration Issue Type: Bug Assignee: Gregory Boissinot Components: envinject Created: 30/Jul/12 9:22 AM Description: I check 'Prepare an environment for the run' and provide the following script content: echo %PATH% I saw that PATH had additional Unix paths I provided at global configuration (my mistake). However, after removing PATH configuration from the global settings, all following builds still show these Unix paths appended. It looks like the plugin did not notice new global configuration and still injects old PATH settings. Environment: Jenkins 1.475 on RHEL5 x86_64, Windows XP slave Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-14569) PATH is not being injected correctly
Krzysztof Malinowski
commented on JENKINS-14569
PATH is not being injected correctly
Additional side effect: on a Windows slave there is predefined environment variable named Path. When setting PATH=C:\Program Files\7-Zip;${PATH} as EnvInject setup, it results in both PATH and Path injected variables, where Path is original (without 7-Zip) and PATH contains 7-Zip. Anyway, the build later fails since apparently Windows checks Path and not PATH (or probably these two count as one and it depends on what order they are set).
As a workaround I have corrected EnvInject setup to set Path not PATH and it works. However, standard environment setup feature from Jenkins did not work this way, i.e. correctly expanded Path with the same setup as above (PATH=C:\Program Files\7-Zip;${PATH})
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-14635) Run EnvInject after building on message
Krzysztof Malinowski
created JENKINS-14635
Run EnvInject after building on message
Issue Type:
Improvement
Assignee:
Gregory Boissinot
Components:
envinject
Created:
31/Jul/12 8:28 AM
Description:
It would be nice if EnvInject could run after echoing 'building on' message. This way two important information ('build started by' and 'building on' messages) would be side by side. Environment cleanup plugin acts after this message but before scm as well, so it should be possible.
Current output
Started by user user
EnvInject - Loading node environment variables.
EnvInject - Preparing an environment for the build.
EnvInject - Keeping Jenkins system variables.
EnvInject - Keeping Jenkins build variables.
EnvInject - Adding build parameters as variables.
EnvInject - Executing and processing the following script content:
cleartool mount \vobtag || exit 0
Jenkins $ cmd /c call D:\Profiles\user\LOCALS~1\Temp\hudson2922408064470202936.bat
D:\Jenkinscleartool mount \vobtag || exit 0
\vobtag is already mounted.
EnvInject - Script executed successfully.
EnvInject - Injecting contributions.
Building remotely on node in workspace workspace
Deleting project workspace... done
projectname $ cleartool lsview viewname
...
Expected output
Started by user user
Building remotely on node in workspace workspace
EnvInject - Loading node environment variables.
EnvInject - Preparing an environment for the build.
EnvInject - Keeping Jenkins system variables.
EnvInject - Keeping Jenkins build variables.
EnvInject - Adding build parameters as variables.
EnvInject - Executing and processing the following script content:
cleartool mount \vobtag || exit 0
Jenkins $ cmd /c call D:\Profiles\user\LOCALS~1\Temp\hudson2922408064470202936.bat
D:\Jenkinscleartool mount \vobtag || exit 0
\vobtag is already mounted.
EnvInject - Script executed successfully.
EnvInject - Injecting contributions.
Deleting project workspace... done
projectname $ cleartool lsview viewname
...
Environment:
Jenkins 1.475 on RHEL5 x86_64, envinject 1.63
Project:
Jenkins
Priority:
Minor
Reporter:
Krzysztof Malinowski
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-14569) PATH is not being injected correctly
Krzysztof Malinowski
created JENKINS-14569
PATH is not being injected correctly
Issue Type:
Bug
Affects Versions:
current
Assignee:
Gregory Boissinot
Components:
envinject
Created:
25/Jul/12 1:59 PM
Description:
On a node level there is PATH environment variable set:
D:\cygwin\bin;${VS71COMNTOOLS}..\IDE;${windir}\Microsoft.NET\Framework\v4.0.30319;${PATH}
Job has been set to set environments variable before SCM checkout with both 'Keep Jenkins Environment Variables' and 'Keep Jenkins Build Variables' checked.
In the build step I put 'echo %PATH%'. It shows that the original PATH is set (without D:\cygwin\bin;${VS71COMNTOOLS}..\IDE;${windir}\Microsoft.NET\Framework\v4.0.30319; part). At the same time in Injected Environment Variables tab I see that PATH was correctly enhanced with settings from node.
The issue did not happen before EnvInject installation and setup. Previously 'echo %PATH%' at build step showed correct path.
Environment:
Jenkins 1.472 on RHEL5 x86_64, Windows Server 2003 slave
Project:
Jenkins
Priority:
Major
Reporter:
Krzysztof Malinowski
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-14569) PATH is not being injected correctly
Krzysztof Malinowski commented on JENKINS-14569 PATH is not being injected correctly OK, now I got similar error on a different project which does not even have EnvInject set. The project used standard 'set environment variables' setting to override PATH and it stopped working once EnvInject was installed. Original PATH setting has been used instead. 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-14382) Error in substituting macro when sending email
Krzysztof Malinowski
created JENKINS-14382
Error in substituting macro when sending email
Issue Type:
Bug
Affects Versions:
current
Assignee:
Slide-O-Mix
Components:
email-ext
Created:
11/Jul/12 10:30 AM
Description:
On a failed build, the following message is shown in the build log when the build comes to sending email:
Error substituting with token-macro plugin: org.jenkinsci.plugins.tokenmacro.MacroEvaluationException: Unrecognized macro 'ConnectionHandler' in '[here comes html mail filled template]'
The email itself is sent to the recipients. The issue also does not occur on successful builds.
It also seems that the issue is not always present for the failed builds. Sometimes mail goes without any errors. It also seems that this 'unrecognized macro' also varies; I just found another occurrence complaining about unrecognized 'AbstractBuildExecution'
I am using globally configured email-ext with content: ${JELLY_SCRIPT, template="html"}
Environment:
Jenkins 1.472 on RHEL 5 x86_64, email-ext 2.22
Project:
Jenkins
Priority:
Minor
Reporter:
Krzysztof Malinowski
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-14328) NPE upon matrix project load
Krzysztof Malinowski created JENKINS-14328 NPE upon matrix project load Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: matrix Created: 05/Jul/12 9:06 PM Description: Upon loading matrix projects it fails: SEVERE: Failed Loading job jobname java.lang.NullPointerException at hudson.matrix.MatrixProject.updateTransientActions(MatrixProject.java:431) at hudson.model.AbstractProject.onLoad(AbstractProject.java:296) at hudson.matrix.MatrixProject.onLoad(MatrixProject.java:466) at hudson.model.Items.load(Items.java:115) at jenkins.model.Jenkins$17.run(Jenkins.java:2492) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:878) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) 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:662) Environment: Jenkins 1.473 on RHEL 5 x86_64 Project: Jenkins Priority: Blocker Reporter: Krzysztof Malinowski 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-14328) NPE upon matrix project load
Krzysztof Malinowski commented on JENKINS-14328 NPE upon matrix project load Reverted to 1.472 and issue disappeared. 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-13895) Plugin fails on custom checkers
Krzysztof Malinowski created JENKINS-13895:
--
Summary: Plugin fails on custom checkers
Key: JENKINS-13895
URL: https://issues.jenkins-ci.org/browse/JENKINS-13895
Project: Jenkins
Issue Type: Bug
Components: klocwork
Affects Versions: current
Environment: Jenkins 1.465 on RHEL5, Klocwork plugin 1.8
Reporter: Krzysztof Malinowski
Assignee: Gregory Boissinot
When kwinspectreport reports custom checkers violation, it does not report
severity, severityLevel and displayAs tags. Parsing then fails with:
The content of element 'problem' is not complete. One of
'{http://www.klocwork.com/inForce/report/1.0:isSystem,
http://www.klocwork.com/inForce/report/1.0:severity,
http://www.klocwork.com/inForce/report/1.0:severitylevel,
http://www.klocwork.com/inForce/report/1.0:displayAs,
http://www.klocwork.com/inForce/report/1.0:comment,
http://www.klocwork.com/inForce/report/1.0:history,
http://www.klocwork.com/inForce/report/1.0:trace,
http://www.klocwork.com/inForce/report/1.0:lastCommitter,
http://www.klocwork.com/inForce/report/1.0:dateFixed,
http://www.klocwork.com/inForce/report/1.0:category,
http://www.klocwork.com/inForce/report/1.0:lastCommit,
http://www.klocwork.com/inForce/report/1.0:taxonomies}' is expected.
--
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-13411) Klocwork XML output is deprecated
[ https://issues.jenkins-ci.org/browse/JENKINS-13411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161580#comment-161580 ] Krzysztof Malinowski commented on JENKINS-13411: Great, but CTO does not mention that web api does not provide line number for issue. And that this is by design. So that even if community creates a script to get it from web api (still don't know why this json-to-xml script cannot be provided with klocwork itself), it won't get a line number so marking source with klocwork finding will no longer be available. Klocwork XML output is deprecated - Key: JENKINS-13411 URL: https://issues.jenkins-ci.org/browse/JENKINS-13411 Project: Jenkins Issue Type: New Feature Components: klocwork Reporter: Krzysztof Malinowski Assignee: gbois As http://www.klocwork.com/products/documentation/current/Kwinspectreport states: XML report is deprecated in KW 9.5 and will no longer be available. I recommend that plugin uses some other parser for the issues (csv maybe) or use web api to get the issues. -- 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-13411) Klocwork XML output is deprecated
Krzysztof Malinowski created JENKINS-13411: -- Summary: Klocwork XML output is deprecated Key: JENKINS-13411 URL: https://issues.jenkins-ci.org/browse/JENKINS-13411 Project: Jenkins Issue Type: New Feature Components: klocwork Reporter: Krzysztof Malinowski Assignee: gbois As http://www.klocwork.com/products/documentation/current/Kwinspectreport states: XML report is deprecated in KW 9.5 and will no longer be available. I recommend that plugin uses some other parser for the issues (csv maybe) or use web api to get the issues. -- 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-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=160946#comment-160946 ] Krzysztof Malinowski commented on JENKINS-12994: Same issue here. All builds are blocked until all quiet periods end. This is a serious disadvantage and I would like to vote for fixing this in the first place. Quiet period is blocking other jobs in queue Key: JENKINS-12994 URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: All, OS: All Reporter: teetoivo Starting from version 1.452, a job in queue waiting for the quiet period to pass is blocking all other jobs that have been queued after it. Example: # Job A has quiet period set to 10 seconds # Job B has quiet period set to 300 seconds # Job C has quiet period set to 100 seconds # Jobs get queued in A-B-C order. # Job A starts executing after 10 seconds # After 100 seconds, status of job C changes to pending - Waiting for next available executor even if free executors are available # After 300 seconds both jobs B and C start executing This problem is hardly visible when short quiet periods are used but becomes problematic with longer quiet periods or plugins like Naginator that will increase the quiet period to hours if the builds fail enough. Version 1.451 is the last release where this problem isn't visible. From public releases, at least 1.452 and 1.454 are affected. -- 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-12861) klocwork - update to recognize 9.5.x xml schema
[
https://issues.jenkins-ci.org/browse/JENKINS-12861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159962#comment-159962
]
Krzysztof Malinowski commented on JENKINS-12861:
Info for maintainer: current output is:
{code:xml|title=kwreport.xml}
?xml version=1.0 encoding=UTF-8?
errorList xmlns=http://www.klocwork.com/inForce/report/1.0; version=9.5.2
problem
problemID1/problemID
file/path/to/hello.c/file
methodmain/method
line8/line
column5/column
codeUNINIT.STACK.MUST/code
messageapos;papos; is used uninitialized in this function./message
anchor112/anchor
prefixain(intargc,char*argv[]){char*p;/prefix
postfixreturn0;}/postfix
trace
traceBlock file=/path/to/hello.c method=main id=0
traceLine line=7 text=apos;papos; is declared type=E/
traceLine line=8 text=apos;papos; is used, but is uninitialized.
type=E/
/traceBlock
/trace
citingStatusAnalyze/citingStatus
stateNew/state
ownerunowned/owner
severityCritical/severity
severitylevel1/severitylevel
displayAsError/displayAs
taxonomies
taxonomy name=C and C++ metaInf=/
/taxonomies
dateOriginated1331140856962/dateOriginated
urlhttp://klocworkserver:8074/review/insight-review.html#goto:project=test,pid=1/url
/problem
/errorList
{code}
klocwork - update to recognize 9.5.x xml schema
---
Key: JENKINS-12861
URL: https://issues.jenkins-ci.org/browse/JENKINS-12861
Project: Jenkins
Issue Type: Improvement
Components: klocwork
Affects Versions: current
Environment: rhel 5.5
Reporter: Greg Moncreaff
Assignee: gbois
schema changed. current plugin can digest
errorList version=9.2.2
...
citingStatusAnalyze/citingStatusstateExisting/stateseverityError/severityseveritylevel3/severityleveldisplayAsError/displayAsdateOriginated1327694645000/dateOriginated
but new owner field appears in 9.5
errorList version=9.5.2
citingStatusAnalyze/citingStatusstateNew/stateownerunowned/ownerseverityCritical/severityseveritylevel1/severityleveldisplayAsError/displayAs
that causes publisher to be less than graceful:
22:08:53 Processing 2 files with the pattern 'kw*.xml'.
22:08:53 Parsing has been canceled. XML Validation failed. See errors below :
22:08:53 At line 47 of
file:/view/mafi_int_kw/vobs/csci33/csc11/kw.xml:cvc-complex-type.2.4.a:
Invalid content was found starting with element 'owner'. One of
'{http://www.klocwork.com/inForce/report/1.0:severity,
http://www.klocwork.com/inForce/report/1.0:severitylevel,
http://www.klocwork.com/inForce/report/1.0:displayAs,
http://www.klocwork.com/inForce/report/1.0:dateOriginated,
http://www.klocwork.com/inForce/report/1.0:url,
http://www.klocwork.com/inForce/report/1.0:comment,
http://www.klocwork.com/inForce/report/1.0:history,
http://www.klocwork.com/inForce/report/1.0:lastCommitter,
http://www.klocwork.com/inForce/report/1.0:dateFixed,
http://www.klocwork.com/inForce/report/1.0:category,
http://www.klocwork.com/inForce/report/1.0:lastCommit}' is expected.
--
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-11898) Create view if view doesn't exist doesn't work for dynamic views
[
https://issues.jenkins-ci.org/browse/JENKINS-11898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158657#comment-158657
]
Krzysztof Malinowski commented on JENKINS-11898:
Another symptom is for base ClearCase:
$ cleartool mkview -tag view_tag
cleartool: Error: View directory pathname must be specified.
Usage: mkview -tag dynamic-view-tag [-tcomment tag-comment] [-tmode text-mode]
[-region network-region | -stream stream-selector]
[-shareable_dos | -nshareable_dos] [-cachesize size]
[-ln link-storage-to-dir-pname] [-ncaexported]
{ -stgloc {view-stgloc-name | -auto}
| [-host hostname -hpath host-stg-pname -gpath global-stg-pname]
dynamic-view-storage-pname
}
mkview -snapshot [-tag snapshot-view-tag]
[-tcomment tag-comment] [-tmode text-mode]
[-cachesize size] [-ptime] [-stream stream-selector]
[ -stgloc view-stgloc-name
| -colocated_server [-host hostname -hpath
host-snapshot-view-pname -gpath global-snapshot-view-pname]
| -vws view-storage-pname [-host hostname -hpath host-stg-pname
-gpath global-stg-pname]
] snapshot-view-pname
FATAL: Base ClearCase failed. exit code=1
Here location for dynamic view is not given at all.
Create view if view doesn't exist doesn't work for dynamic views
Key: JENKINS-11898
URL: https://issues.jenkins-ci.org/browse/JENKINS-11898
Project: Jenkins
Issue Type: Bug
Components: clearcase
Affects Versions: current
Environment: unix
Reporter: Eric Le Lay
Assignee: Vincent Latombe
Attachments: fix+ClearCase+dynamic+view+creation.patch
(tested with 1.3.7)
When I check use dynamic views and Create view if view doesn't exist, the
command line generated is such :
cleartool mkview -snapshot -stream NAME_OF_THE_STREAM_OK -tag VIEWTAG_OK
-stgloc -auto
Here you see a nasty -snapshot argument making troubles.
The error message is cleartool: Error: View directory pathname must be
specified.
--
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
