[JIRA] (JENKINS-49897) gerrit-plugin pr branch names are incorrectly name
Title: Message Title Jose Sa commented on JENKINS-49897 Re: gerrit-plugin pr branch names are incorrectly name I also consider that we should only consider the gerrit review id (6 digits number) as the branch name, and treat it the same way as the other actual branches. This way all individual patches, manual replays, etc... will be displayed in the history of that branch, retaining a build history while the review is open. As it is right now, once a new patchset is uploaded previous related builds are destroyed and only the latest patchset "job" is available, effectively loosing history and for me that is a serious bug. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38046) Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline
Title: Message Title
Jose Sa commented on JENKINS-38046
Re: Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline
I'm using this trigger in multi-branch but seems to be ignored:
triggers {
gerrit(
serverName: 'server-name',
gerritProjects: [[
compareType: 'PLAIN',
pattern: '_REPO_',
branches: [[ compareType: 'ANT', pattern: 'refs/heads/*' ]],
filePaths: [[ compareType: 'ANT', pattern: "_MODULE_/**" ]],
disableStrictForbiddenFileVerification: false
]],
triggerOnEvents: [
refUpdated()
]
)
}
The only thing that makes build happen is the polling scheduled every 5 minutes (as workaround) checking for branch changes. Should I use something differently to get multibranch jobs triggered ?
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-48167) Support gerrit trigger configuration in pipeline syntax
Title: Message Title
Jose Sa edited a comment on JENKINS-48167
Re: Support gerrit trigger configuration in pipeline syntax
I've been using this sample code for gerrit triggers in single Jenkinsfile (for standard job):{code} triggers {gerrit( serverName: ' nokia server - gerrit name ', gerritProjects: [[compareType: 'PLAIN',pattern: '_REPO_',branches: [[ compareType: 'PLAIN', pattern: 'master' ]],filePaths: [[ compareType: 'ANT', pattern: "_MODULE_/**" ]],disableStrictForbiddenFileVerification: false ]], triggerOnEvents: [changeMerged(),patchsetCreated(excludeDrafts: true, excludeNoCodeChange: false, excludeTrivialRebase: false) ]) }{code}For multi-branch jobs gerrit triggers seem to be ignored though ...
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-48167) Support gerrit trigger configuration in pipeline syntax
Title: Message Title
Jose Sa commented on JENKINS-48167
Re: Support gerrit trigger configuration in pipeline syntax
I've been using this sample code for gerrit triggers in single Jenkinsfile (for standard job):
triggers {
gerrit(
serverName: 'nokia-gerrit',
gerritProjects: [[
compareType: 'PLAIN',
pattern: '_REPO_',
branches: [[ compareType: 'PLAIN', pattern: 'master' ]],
filePaths: [[ compareType: 'ANT', pattern: "_MODULE_/**" ]],
disableStrictForbiddenFileVerification: false
]],
triggerOnEvents: [
changeMerged(),
patchsetCreated(excludeDrafts: true, excludeNoCodeChange: false, excludeTrivialRebase: false)
]
)
}
For multi-branch jobs gerrit triggers seem to be ignored though ...
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
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-11174) time rules uses different time-stamp from build start
Title: Message Title Jose Sa commented on JENKINS-11174 Re: time rules uses different time-stamp from build start Thanks 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] [robot-plugin] (JENKINS-22546) Add REST API to robot framework plugin
Jose Sa commented on JENKINS-22546 Add REST API to robot framework plugin I've tested this plugin with version 1.5.0 and while the robot general information about the specific build is available (total number of tests, tests passed/failed, pecentage of tests passed), the information about the individual failed test cases is missing. Sample output using xml rest api: robotResult allFailedCase/ allFailedCase/ allFailedCase/ criticalFailed3/criticalFailed criticalPassed27/criticalPassed criticalTotal30/criticalTotal overallFailed3/overallFailed overallPassed27/overallPassed overallTotal30/overallTotal passPercentage90.0/passPercentage suite/ timeStamp20140523 15:24:06.067/timeStamp /robotResult I tried adding "?depth=2" or "?depth=3" to see if more information would be displayed on sub-levels but it returned the same output. 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] [robot-plugin] (JENKINS-22546) Add REST API to robot framework plugin
Jose Sa commented on JENKINS-22546 Add REST API to robot framework plugin Primarily we are interested in the “failed test cases” table content as shown in robot reports page, the “all test suites” may also be useful but that is secondary. 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] [robot-plugin] (JENKINS-22546) Add REST api to robot framwork plugin
Jose Sa created JENKINS-22546 Add REST api to robot framwork plugin Issue Type: Improvement Assignee: jpiironen Components: robot-plugin Created: 09/Apr/14 12:51 PM Description: It would be usefull if we could obtain some values from REST api like the "Age" of tests detected as failing. Environment: Robot Framework plugin v1.4.2 Fix Versions: current Project: Jenkins Labels: rest Priority: Major Reporter: Jose Sa 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] [robot-plugin] (JENKINS-22546) Add REST API to robot framework plugin
Jose Sa updated JENKINS-22546 Add REST API to robot framework plugin Change By: Jose Sa (09/Apr/14 12:51 PM) Summary: AddREST api API torobot framwork framework 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/d/optout.
[JIRA] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials
Jose Sa commented on JENKINS-21785 Check for changes in folders linked via svn:externals fails due to missing credentials Seems like a big hassle to get authentication done. I would like to keep this as simple as possible by just identifying the hosts domain using wildcards ie: "*.svn-repos.org" no differences in protocol (https, http, svn+ssl...) or authentication realms. If I have the same account with username/password that has access to multiple repositories in multiple servers, why should I have to enter it a thousand times in many different ways because of variations of protocols and realm strings ?? 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] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials
Jose Sa commented on JENKINS-21785 Check for changes in folders linked via svn:externals fails due to missing credentials After some additional testing it seems that subversion plugin is relying on host svn client configuration looking into $HOME/.subversion for the credentials instead of of using the ones configured in Jenkins. When I used a Windows slave that didn't had a svn client installed or removed .subversion on linux slaves or master the problem to check on all urls is shown in scm polling log. 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] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials
Jose Sa commented on JENKINS-21785 Check for changes in folders linked via svn:externals fails due to missing credentials I had enable the polling from master option on startup "-Dhudson.scm.SubversionSCM.pollFromMaster=true" and after disabling it and restarting server, rechecking the polling from the slave instead of master now all urls fail to check with same stack trace. svn checkout doesn't seem to have a problem. Tested with Jenkins LTS 1.532.2 and svn plugin 2.2 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] [subversion] (JENKINS-17616) Performance issue with Subversion plugin - trigger build on SVN commit takes too long
Jose Sa commented on JENKINS-17616 Performance issue with Subversion plugin - trigger build on SVN commit takes too long This seems to be working better with caching (tested with svn plugin 2.2), however due to credentials refactoring affecting svn:externals JENKINS-21785 there are still some issues that makes some cache misses. 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] [subversion] (JENKINS-17616) Performance issue with Subversion plugin - trigger build on SVN commit takes too long
Jose Sa commented on JENKINS-17616 Performance issue with Subversion plugin - trigger build on SVN commit takes too long Nice. Looking forward to test this. 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] [livescreenshot] (JENKINS-20801) Screenshot in View Columns shows duplicated
Jose Sa commented on JENKINS-20801 Screenshot in View Columns shows duplicated I've tested this in my Windows 7 64-bit running with "java -jar jenkins.war". I'll try also with other OS for comparison. 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] [livescreenshot] (JENKINS-20801) Screenshot in View Columns shows duplicated
Jose Sa updated JENKINS-20801 Screenshot in View Columns shows duplicated tested also in my production servers in Solaris 10 and RHEL 6.2 and it has the same behaviour. Maybe the plugin you tested compiled from sources does work, but the one available in Jenkins update center with version 1.4.4 (and the previous one 1.4.3) have this behavior. Change By: Jose Sa (28/Nov/13 2:21 PM) Attachment: double_screenshots.png 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] [livescreenshot] (JENKINS-20801) Screenshot in View Columns shows duplicated
Jose Sa commented on JENKINS-20801 Screenshot in View Columns shows duplicated yes this was tested with regular jobs. 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] [livescreenshot] (JENKINS-20801) Screenshot in View Columns shows duplicated
Jose Sa commented on JENKINS-20801 Screenshot in View Columns shows duplicated Thanks. 1.4.5 fixes this issue now. 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] [livescreenshot] (JENKINS-20801) Screenshot in View Columns shows duplicated
Jose Sa created JENKINS-20801 Screenshot in View Columns shows duplicated Issue Type: Bug Assignee: Unassigned Components: livescreenshot Created: 28/Nov/13 2:40 AM Description: When job is active the screenshot column shows the same thumbnail image twice instead of just once. Environment: Jenkins ver. 1.509.4 LiveScreenshot Plugin 1.4.4 Project: Jenkins Priority: Major Reporter: Jose Sa 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] [swarm] (JENKINS-20668) Persist Jenkins swarm slaves when they go offline
Jose Sa created JENKINS-20668 Persist Jenkins swarm slaves when they go offline Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: swarm Created: 20/Nov/13 10:37 AM Description: Whenever there is a problem with a swarm slave that causes its disconnection the slave just disappears. This prevents on first acknowledging there is a problem with that particular slave and secondly finding out more from logs. One possible solution is to have a "sticky" option in slave configuration so to make it persistent in case it goes offline. Another possible solution would be to add in general configuration some time based options for "swarm" specific slaves: connection timeout (ex 15 min) removal timeout (ex: 1 day) The basic idea is the same, to provide more transparency of the status of slaves instead of hiding them when something goes wrong. Project: Jenkins Priority: Major Reporter: Jose Sa 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] [subversion] (JENKINS-17616) Performance issue with Subversion plugin - trigger build on SVN commit takes too long
Jose Sa updated JENKINS-17616 Performance issue with Subversion plugin - trigger build on SVN commit takes too long I have the same problem after upgrading jenkins svn plugin to 1.45 or later. The svn post-commit just times out with following visible message in user side: HTTP request sent, awaiting response... Read error (Connection timed out) in headers. Read error (Connection timed out) in headers. No immediate exception is produced in Jenkins console, but after a long time I noticed some exceptions being displayed about this timeout and failure to handle post-commit notification, see exception_long_after_timeout.txt Change By: Jose Sa (20/Jun/13 7:49 AM) Attachment: exception_long_after_timeout.txt 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] [subversion] (JENKINS-17616) Performance issue with Subversion plugin - trigger build on SVN commit takes too long
Jose Sa commented on JENKINS-17616 Performance issue with Subversion plugin - trigger build on SVN commit takes too long Additional info: I've experienced this With jenkins masters running both in Solaris 10 sparc and RHEL6.2 x86_64, with lot of jobs in them. Up to subversion plugin 1.44 the post-commit doesn't have any delay so that's the one we are currently using. On newly fresh installations this problem doesn't seem to happen, so it may be either factored by the amount of jobs or combination of plugins that could be causing this. If anyone has any idea how to troubleshoot this and pinpoint the problem I'll be glad to experiment it. 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] [ec2] (JENKINS-14965) Instance limits improvement
Jose Sa commented on JENKINS-14965 Instance limits improvement It would make some sense to make the plugin check for maximum limits on different levels: Globally (current behavior): check for limit of instances deployed for the same user in that cloud Locally: check for limit of instances deployed by current Jenkins master Instance: check for limit of instances deployed for a particular AMI Minimum limits could also be defined on Instance level if needed to have a small starting set of instances and expand to more on load demand. 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] [subversion] (JENKINS-13538) Build hangs at SVN update occasionally
Jose Sa commented on JENKINS-13538 Build hangs at SVN update occasionally I still have this problem in 1.491 (don't have more recent yet), but already tried recent svn plugin versions (1.40-1.45). I found out that using in svn urls http instead of https does help avoiding the hanging issue. I've tested this running 2 jobs (basically just doing svn update) using the exact same url every 2 minutes. This is basically a workaround since it may mean the plugin (or svnkit) has some problem with handling https urls. 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-15587) Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39
Jose Sa commented on JENKINS-15587 Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39 Check the scripts I've added in JENKINS-17265 which may help you detect and cleanup those kind of situations. 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-17265) Builds disappearing from history
Jose Sa updated JENKINS-17265 Builds disappearing from history Change By: Jose Sa (03/Apr/13 10:29 PM) Attachment: check_invalid_builds.sh Attachment: check_missing_builds.sh 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-17265) Builds disappearing from history
Jose Sa commented on JENKINS-17265 Builds disappearing from history Allowing jobs with spaces in names does complicate things, making it harder (but not impossible) to handle via script. I prefer not to allow any spaces using "Create Job Advanced" plugin to enforce some common rules. To allow spaces, basically any path that contains the job name should be enclosed with double quotes either on variable assignment as well in usage. Since command "find" doesn't like to have wildcard enclosed in double quotes, that can be split into first a change directory and then the find command with wildcard. I uploaded new versions of scripts but it didn't seem to have replaced the old ones when uploaded, so refer to the most recent ones. Jenkins on Windows also seems to have a different behavior since it doesn't seem to use any symbolic links (not visible on cygwin anyway with 1.484), so the the link related checks probably are not applicable on Windows. 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-17265) Builds disappearing from history
Jose Sa updated JENKINS-17265 Builds disappearing from history After some analysis of my previous script I realized it contained a lot of false positives possibly due to years of accumulated history of broken builds, java crashes, wrong copying of jobs between servers, etc, that lead to the following most common cases: numbered links pointing to removed build directories (solution: remove links) build directories without build.xml file (solution: remove directories) build directories without numbered links (solution: create links) build directories not in date format (solution: delete directories) Since this is a common cause many I created a simple script to detect those common problems with optional cleanup (passing argument '-c') - Unable to embed resource: check_invalid_builds.sh of type application/x-sh Also the same script for checking the missing builds as given as excerpt above - Unable to embed resource: check_missing_builds.sh of type application/x-sh Tested in RHEL6 and Solaris 10 (with gnu utils) Change By: Jose Sa (01/Apr/13 4:24 AM) Attachment: check_invalid_builds.sh Attachment: check_missing_builds.sh 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-17265) Builds disappearing from history
Jose Sa edited a comment on JENKINS-17265 Builds disappearing from history After some analysis of my previous script I realized it contained a lot of false positives possibly due to years of accumulated history of broken builds, java crashes, wrong rsync of jobs between servers, etc, that lead to the following most common problems: numbered links pointing to removed build directories (solution: remove links) build directories without build.xml file (solution: remove directories) build directories without numbered links (solution: create links) build directories not in date format (solution: delete directories) Since these happen often I created some scripts to: Detect those common problems with optional cleanup (passing argument '-c') - check_invalid_builds.sh Checking the missing builds as given as excerpt above - check_missing_builds.sh NOTE: to effectively apply the cleanups first run the script without '-c' to run in preview mode and review the suggestions, when ready to apply them shutdown Jenkins first so that there are no files pending in memory to be written to file system. Tested in RHEL6 and Solaris 10 (with gnu utils) 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-17265) Builds disappearing from history
Jose Sa commented on JENKINS-17265 Builds disappearing from history Got this exception on some jobs when doing the wget for job/buildHistory/all a few minutes after jenkins was restarted. Mar 29, 2013 9:26:04 PM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.renderList in /hudson/job/PM_OSS5_EBSS_LV2_FUNCTIONAL_GA12/buildHistory/all. Reason: java.lan g.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) 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._expression_.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateAsIterator(ExpressionSupport.java:94) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:89) 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.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.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.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) 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.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.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) 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
[JIRA] (JENKINS-17265) Builds disappearing from history
Jose Sa commented on JENKINS-17265 Builds disappearing from history I'm with core 1.505 now. Tried more recent versions like 1,505, 1.506 and 1.508, but had to revert back due worse problems caused by NPE not being able to load jobs like the previous issue, but now extended to Promote plugin JENKINS-17381 along with weird changed in SSH Slaves plugin credentials definitions that got all messed up. 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-17265) Builds disappearing from history
Jose Sa edited a comment on JENKINS-17265 Builds disappearing from history I'm with core 1.505 now. Tried more recent versions like 1.506 and 1.508, but had to revert back due worse problems caused by NPE not being able to load jobs like the previous issue, but now extended to Promote plugin JENKINS-17381 along with weird changed in SSH Slaves plugin credentials definitions that got all messed up. 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-17265) Builds disappearing from history
Jose Sa
commented on JENKINS-17265
Builds disappearing from history
Both "/api/json?tree=buildsnumber" and "/rssAll" job urls seem to be returning only latest builds (not all as expected), like I wrote above this could be a symptom for this case.
Luckily "/buildHistory/all" does still provide all visible builds, so I was able to create created a bash script to help automatically to check for this kind of problems and provide a text report.
# Assuming some host specific variables
jenkins_url=https://localhost:8080
jobs_dir=/work/jenkins/jobs
# This should work for any unix environment using bash
for job_dir in ${jobs_dir}/*; do
job=$(basename ${job_dir})
echo "Checking $job..." 2
job_url=${jenkins_url}/job/${job}
wget -q --no-check-certificate -O all ${job_url}/buildHistory/all
gawk -F'#' '/ #/{print $2}' all online_builds
find ${jobs_dir}/${job}/builds/* * -type l ! -name "last*" -prune | sed "s,${jobs_dir}/${job}/builds/,,g" local_builds
missing=$(gawk '
BEGIN {first_file = ""}
{
if (first_file == "") first_file = FILENAME
if (first_file == FILENAME) {build_list[$1]=1} else {delete build_list[$1]}
}
END {for (build in build_list) print build}
' local_builds online_builds)
[ ! -z "${missing}" ] echo Job $job missing builds: $missing
done | tee missing_builds.txt
I found out that after 3 days online, 85 (out of 1406) jobs are showing missing builds varying from a few to all.
I have FreeStyle and MultiJob types and they both show this problem.
We are using mixed ClearCase and SVN (both showing same problems)
Server is Solaris 10 Sparc, having slaves on HP-UX, Windows (XP, 2k3, 7), RHEL (5, 6), Solaris.
Running Jenkins from war file, currently with 1.505 (but noticing this problem since 1.485)
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-17265) Builds disappearing from history
Jose Sa
edited a comment on JENKINS-17265
Builds disappearing from history
Both "/api/json?tree=buildsnumber" and "/rssAll" job urls seem to be returning only latest builds (not all as expected), like I wrote above this could be a symptom for this case.
Luckily "/buildHistory/all" does still provide all visible builds, so I was able to create created a bash script to help automatically to check for this kind of problems and provide a text report.
# Assuming some host specific variables
jenkins_url=https://localhost:8080
jobs_dir=/work/jenkins/jobs
# This should work for any unix environment using bash
for job_dir in ${jobs_dir}/*; do
job=$(basename ${job_dir})
echo "Checking $job..." 2
job_url=${jenkins_url}/job/${job}
wget -q --no-check-certificate -O all ${job_url}/buildHistory/all
gawk -F'#' '/ #/{print $2}' all online_builds
find ${jobs_dir}/${job}/builds/* -type l ! -name "last*" -prune | sed "s,${jobs_dir}/${job}/builds/,,g" local_builds
missing=$(gawk '
BEGIN {first_file = ""}
{
if (first_file == "") first_file = FILENAME
if (first_file == FILENAME) {build_list[$1]=1} else {delete build_list[$1]}
}
END {for (build in build_list) print build}
' local_builds online_builds)
[ ! -z "${missing}" ] echo Job $job missing builds: $missing
done | tee missing_builds.txt
I found out that after 3 days online, 85 (out of 1406) jobs are showing missing builds varying from a few to all.
I have FreeStyle and MultiJob types and they both show this problem.
We are using mixed ClearCase and SVN (both showing same problems)
Server is Solaris 10 Sparc, having slaves on HP-UX, Windows (XP, 2k3, 7), RHEL (5, 6), Solaris.
Running Jenkins from war file, currently with 1.505 (but noticing this problem since 1.485)
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-17265) Builds disappearing from history
Jose Sa commented on JENKINS-17265 Builds disappearing from history I was trying to create some script to crosscheck locally available builds with the ones reported on web page using REST api appending to job "/api/json?tree=buildsnumber" and noticed something curious, not all builds are reported in that list when comparing with the ones actually visible in build history, only the most recent ones on variable ammount. Not sure if there is any limitation/restriction to the api, but maybe this is a symptom of this problem because if it already thinks it has less builds that it actually has, on some cleanup procedure it might only keep the ones reported and discard the rest. 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-17265) Builds disappearing from history
Jose Sa commented on JENKINS-17265 Builds disappearing from history Please notice that "Reload from disk" may be unsafe if you have actively running jobs as indicated in JENKINS-3265 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-16845) NullPointer in getPreviousBuild
Jose Sa commented on JENKINS-16845 NullPointer in getPreviousBuild Jenkins upgraded to 1.505, but errors still shown during initialization causing jobs to fail loading: INFO: Augmented all extensions Mar 12, 2013 12:27:27 PM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Loading job RS_OSS5_ACOMNDS_LV2_BRINGUP_GA68 java.lang.NullPointerException at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:214) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:319) at hudson.model.RunMap.retrieve(RunMap.java:226) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:657) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:640) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:446) at jenkins.model.lazy.AbstractLazyLoadRunMap.newestBuild(AbstractLazyLoadRunMap.java:311) at hudson.model.AbstractProject.getLastBuild(AbstractProject.java:1043) at hudson.model.AbstractProject.getLastBuild(AbstractProject.java:140) at hudson.plugins.robot.RobotProjectAction.getLastBuildWithRobot(RobotProjectAction.java:114) at hudson.plugins.robot.RobotProjectAction.getLastBuildAction(RobotProjectAction.java:67) at hudson.plugins.robot.RobotPublisher.getProjectActions(RobotPublisher.java:210) at hudson.model.Project.createTransientActions(Project.java:211) at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:701) at hudson.model.AbstractProject.onLoad(AbstractProject.java:300) at hudson.model.Project.onLoad(Project.java:83) at hudson.model.Items.load(Items.java:221) at jenkins.model.Jenkins$17.run(Jenkins.java:2540) 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:883) 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.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 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-17125) FingerprintAction Serializiation Bug
Jose Sa commented on JENKINS-17125 FingerprintAction Serializiation Bug In 1.502 some jobs fail to load due to the NullPointer exception in getPreviousBuild. 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-8971) Keep only last promoted build forever
Jose Sa commented on JENKINS-8971 Keep only last promoted build forever It would be interesting indeed that the builds "kept" had some configurations for automatic cleanup, like keeping only the last X number of builds of a given promotion. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Jose Sa commented on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException I've added that entry to my startup script 2 weeks ago and also haven't experienced 100% cpu symptom since then. 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-12629) Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate
Jose Sa commented on JENKINS-12629 Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate I tried using the suggestion with 'ssh host groovy = file', on 1.491 and 1.501 and both still fails with message "This command can only run with Jenkins CLI. See https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI" 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-16845) NullPointer in getPreviousBuild
Jose Sa created JENKINS-16845 NullPointer in getPreviousBuild Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: core Created: 16/Feb/13 11:35 PM Description: After upgrading to latest 1.501 (from 1.484) I see this error a lot in my Jenkins log surging from several actions: scm polling, columns sort, dashboard views, etc. Feb 16, 2013 6:00:55 PM hudson.triggers.SCMTrigger$Runner runPolling SEVERE: Failed to record SCM polling for hudson.model.FreeStyleProject@4dcc1f71[PM_OSS5_ACOMHFE_ADAPTATION_LV1] java.lang.NullPointerException at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:213) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:320) at hudson.model.RunMap.retrieve(RunMap.java:226) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:645) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:608) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:347) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:505) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:358) at jenkins.model.lazy.AbstractLazyLoadRunMap.newestBuild(AbstractLazyLoadRunMap.java:300) at hudson.model.AbstractProject.getLastBuild(AbstractProject.java:1021) at hudson.model.AbstractProject.poll(AbstractProject.java:1387) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:439) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:468) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) I've disabled Downstream+buildview+plugin because of this error some hobs woudln't even load, while other plugins like DashboardView would get dogslow while still throwing this same stacktrace, but still the same stack trace keeps comming up even in the most basic things like SCM Polling. Please check. Environment: core 1.501 Project: Jenkins Priority: Critical Reporter: Jose Sa 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-16845) NullPointer in getPreviousBuild
Jose Sa
updated JENKINS-16845
NullPointer in getPreviousBuild
Change By:
Jose Sa
(16/Feb/13 11:36 PM)
Description:
Afterupgradingtolatest1.501(from1.484)IseethiserroralotinmyJenkinslogsurgingfromseveralactions:scmpolling,columnssort,dashboardviews,etc.{code}Feb16,20136:00:55PMhudson.triggers.SCMTrigger$RunnerrunPollingSEVERE:FailedtorecordSCMpollingforhudson.model.FreeStyleProject@4dcc1f71[PM_OSS5_ACOMHFE_ADAPTATION_LV1]java.lang.NullPointerExceptionathudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:213)athudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349)athudson.model.Run.onLoad(Run.java:320)athudson.model.RunMap.retrieve(RunMap.java:226)athudson.model.RunMap.retrieve(RunMap.java:59)atjenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:645)atjenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:608)atjenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:347)atjenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:505)atjenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:358)atjenkins.model.lazy.AbstractLazyLoadRunMap.newestBuild(AbstractLazyLoadRunMap.java:300)athudson.model.AbstractProject.getLastBuild(AbstractProject.java:1021)athudson.model.AbstractProject.poll(AbstractProject.java:1387)athudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:439)athudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:468)athudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)atjava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)atjava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)atjava.util.concurrent.FutureTask.run(FutureTask.java:166)atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)atjava.lang.Thread.run(Thread.java:722){code}IvedisabledDownstream+buildview+pluginbecauseofthiserrorsome
hobswoudln
jobswouldn
tevenload,whileotherpluginslikeDashboardViewwouldgetdogslowwhilestillthrowingthissamestacktrace,butstillthesamestacktracekeeps
comming
showing
upeveninthemostbasicthingslikeSCMPolling.Pleasecheck.
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-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Jose Sa commented on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 I managed to perform the upgrade without failing to load jobs by disabling the Downstream buildview plugin. Maybe this info will help others with similar 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] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Jose Sa edited a comment on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 I managed to perform the upgrade to 1.501 without failing to load jobs by disabling the Downstream buildview plugin. Maybe this info will help others with similar 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] (JENKINS-12629) Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate
Jose Sa
commented on JENKINS-12629
Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate
I had that problem too, but managed to workaround it with groovysh redirecting from standard input. It must be a bug that "groovy" command doesn't not work wuth SSH CLI.
If you don't care about output returned you don't even need to filter it out, but here is an example how to bulk apply some changes to subversion update strategy on all jobs with e certain regular _expression_ pattern:
## List jobs
JOBS_PAT=".*_analysis"
cat _EOF_ list-jobs.groovy
for (job in Hudson.instance.items.findAll{ it.name =~ /^${JOBS_PAT}$/ }) println job.name;
exit
_EOF_
jobs=$(jcli groovysh list-jobs.groovy | tail -n +4 | head -n -2 | sed "s,^[^ ]*groovy[^ ]*,,")
## get jobs
mkdir -p old
for job in $jobs; do
echo $job
jcli get-job $job old/$job.xml
done
## change jobs
mkdir -p new
for job in $jobs; do
echo $job
sed 's/workspaceUpdater class.*/workspaceUpdater class="hudson.scm.subversion.UpdateWithRevertUpdater"\/' old/$job.xml new/$job.xml
diff old/$job.xml new/$job.xml
done
## update jobs
for job in $jobs; do
echo $job
jcli update-job $job new/$job.xml
done
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-12629) Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate
Jose Sa
edited a comment on JENKINS-12629
Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate
I had that problem too, but managed to workaround it with groovysh redirecting from standard input. It must be a bug that "groovy" command doesn't not work with SSH CLI.
If you don't care about output returned you don't even need to filter it out, but here is an example how to bulk apply some changes to subversion update strategy on all jobs with e certain regular _expression_ pattern:
## List jobs
JOBS_PAT=".*_analysis"
cat _EOF_ list-jobs.groovy
for (job in Hudson.instance.items.findAll{ it.name =~ /^${JOBS_PAT}$/ }) println job.name;
exit
_EOF_
jobs=$(jcli groovysh list-jobs.groovy | tail -n +4 | head -n -2 | sed "s,^[^ ]*groovy[^ ]*,,")
## get jobs
mkdir -p old
for job in $jobs; do
echo $job
jcli get-job $job old/$job.xml
done
## change jobs
mkdir -p new
for job in $jobs; do
echo $job
sed 's/workspaceUpdater class.*/workspaceUpdater class="hudson.scm.subversion.UpdateWithRevertUpdater"\/' old/$job.xml new/$job.xml
diff old/$job.xml new/$job.xml
done
## update jobs
for job in $jobs; do
echo $job
jcli update-job $job new/$job.xml
done
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-12629) Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate
Jose Sa updated JENKINS-12629 Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate There is currently a better alternative which is to use SSH directly, if you configure Jenkins to lister on a sshd port on your choosing (example 12345). This way you can execute cli commands like this: alias jcli='ssh -p 12345 $JENKINS_HOST' jcli help All you need to make sure is to publish your public ssh key in your Jenkins account. Change By: Jose Sa (07/Feb/13 2:52 PM) Priority: Critical Major 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-15587) Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39
Jose Sa commented on JENKINS-15587 Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39 I had to do some forced updated yesterday and run into this issue in RHEL6 hosts, so I've investigated further in the filesystem. It turned out that there were actually some folders named like build numbers instead of dates. They must have started as normal symbolic link pointing to directory with date, but they weren't anymore. Here is how you can do a search for those problematic directories in linux/cygwin using bash: find $JENKINS_HOME/jobs -type d | egrep ".*/builds/[0-9]+$" One hypothesis for this happening could be that when "moving" jobs between servers the symbolic links were not retained properly. If you don't need those specific builds, the easiest way is probably to just delete those folders and retry the upgrade. 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-15587) Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39
Jose Sa commented on JENKINS-15587 Builds disappear from jobs - hudson.util.IOException2: Invalid directory name - java.text.ParseException: Unparseable date: 39 Im using Solaris 10 Sparc and also have the same problem, so it is not NTFS specific. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Jose Sa commented on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException I still have this problem occurring at least twice a week causing cpu at 400% (on a 4 CPUs machine) that forces me to restart the server. When it happens I can workaround it (temporarily) by using the 'monitoring' plugin, going to the list of threads and sort the table by execution time and kill the threads actively running "DeflaterOutputStream.deflate" that are on top of the table. This makes CPU drop back to normal values but eventually a restart will be needed at the end of the day. Here is a stack trace collected from our logs: WARNING: Untrapped servlet exception winstone.ClientSocketException: Failed to write to client at winstone.ClientOutputStream.write(ClientOutputStream.java:41) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119) at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112) at java.util.zip.GZIPOutputStream.finish(GZIPOutputStream.java:169) at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238) at org.kohsuke.stapler.compression.FilterServletOutputStream.close(FilterServletOutputStream.java:36) at net.bull.javamelody.FilterServletOutputStream.close(FilterServletOutputStream.java:46) at java.io.FilterOutputStream.close(FilterOutputStream.java:160) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at java.io.BufferedWriter.close(BufferedWriter.java:266) at org.dom4j.io.XMLWriter.close(XMLWriter.java:286) at org.kohsuke.stapler.jelly.HTMLWriterOutput.close(HTMLWriterOutput.java:70) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:56) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) 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$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$4.doDispatch(MetaClass.java:203) 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: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.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at
[JIRA] (JENKINS-15794) Subversion commit notifications should not be performed on disabled jobs
Jose Sa
created JENKINS-15794
Subversion commit notifications should not be performed on disabled jobs
Issue Type:
Bug
Assignee:
Unassigned
Components:
subversion
Created:
10/Nov/12 1:39 AM
Description:
In our Jenkins server we have some disabled jobs as templates with generic names like {stream}{branch}{module}_{purpose} which also have in its content the subversion url as template format "https://{svn_url}"
We noticed a lot of warnings in our logs (2000 per hour) regarding subversion commit notifications involving these disabled jobs because it cant recognize the url.
Nov 9, 2012 6:27:59 PM hudson.scm.SubversionRepositoryStatus doNotifyCommit
WARNING: Failed to handle Subversion commit notification
org.tmatesoft.svn.core.SVNException: svn: OPTIONS failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:533)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1011)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:99)
at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2379)
at hudson.scm.SubversionRepositoryStatus.doNotifyCommit(SubversionRepositoryStatus.java:111)
at sun.reflect.GeneratedMethodAccessor399.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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$1.doDispatch(MetaClass.java:111)
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 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.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 net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
at
[JIRA] (JENKINS-15794) Subversion commit notifications should not be performed on disabled jobs
Jose Sa
updated JENKINS-15794
Subversion commit notifications should not be performed on disabled jobs
Change By:
Jose Sa
(10/Nov/12 1:40 AM)
Description:
InourJenkinsserverwehavesomedisabledjobsastemplateswithgenericnameslike
{stream}
\
_{branch}
\
_{module}
\
_{purpose}
whichalsohaveinitscontentthesubversionurlastemplateformathttps://{svn_url}Wenoticedalotofwarningsinourlogs(2000perhour)regardingsubversioncommitnotificationsinvolvingthesedisabledjobsbecauseitcantrecognizetheurl.{code}Nov9,20126:27:59PMhudson.scm.SubversionRepositoryStatusdoNotifyCommitWARNING:FailedtohandleSubversioncommitnotificationorg.tmatesoft.svn.core.SVNException:svn:OPTIONSfailedatorg.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298)atorg.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)atorg.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)atorg.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:533)atorg.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)atorg.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1011)atorg.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:99)athudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2379)athudson.scm.SubversionRepositoryStatus.doNotifyCommit(SubversionRepositoryStatus.java:111)atsun.reflect.GeneratedMethodAccessor399.invoke(UnknownSource)atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)atjava.lang.reflect.Method.invoke(Method.java:616)atorg.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)atorg.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)atorg.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)atorg.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:488)atorg.kohsuke.stapler.Stapler.service(Stapler.java:162)atjavax.servlet.http.HttpServlet.service(HttpServlet.java:45)atwinstone.ServletConfiguration.execute(ServletConfiguration.java:248)atwinstone.RequestDispatcher.forward(RequestDispatcher.java:333)atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)atnet.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206)atnet.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179)atnet.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)atorg.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)athudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)athudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194)atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)athudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194)atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84){code}Thiskindofoperationsrunninghudson.scm.SubversionRepositoryStatusdoNotifyCommitshouldnotbeinvolvingdisabledjobsinthefirstplace.
[JIRA] (JENKINS-15794) Subversion commit notifications should not be performed on disabled jobs
Jose Sa
updated JENKINS-15794
Subversion commit notifications should not be performed on disabled jobs
Change By:
Jose Sa
(10/Nov/12 1:45 AM)
Description:
InourJenkinsserverwehavesomedisabledjobsastemplateswithgenericnameslike{stream}\_{branch}\_{module}\_{purpose}whichalsohaveinitscontentthesubversionurlastemplateformathttps://{svn_url}Wenoticedalotofwarningsinourlogs(2000perhour)regardingsubversioncommitnotificationsinvolvingthesedisabledjobsbecauseitcantrecognizetheurl.
{code}
Nov9,20126:27:59PMhudson.scm.SubversionRepositoryStatusdoNotifyCommitWARNING:FailedtohandleSubversioncommitnotificationorg.tmatesoft.svn.core.SVNException:svn:OPTIONSfailedatorg.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298)atorg.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)atorg.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)atorg.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:533)atorg.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)atorg.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1011)atorg.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:99)athudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2379)athudson.scm.SubversionRepositoryStatus.doNotifyCommit(SubversionRepositoryStatus.java:111)atsun.reflect.GeneratedMethodAccessor399.invoke(UnknownSource)atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)atjava.lang.reflect.Method.invoke(Method.java:616)atorg.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)atorg.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)atorg.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)atorg.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384)atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659)atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:488)atorg.kohsuke.stapler.Stapler.service(Stapler.java:162)atjavax.servlet.http.HttpServlet.service(HttpServlet.java:45)atwinstone.ServletConfiguration.execute(ServletConfiguration.java:248)atwinstone.RequestDispatcher.forward(RequestDispatcher.java:333)atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)atnet.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206)atnet.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179)atnet.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)atorg.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)athudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)athudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194)atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)athudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194)atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Jose Sa commented on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 With 1.487 I still have same problem (i'm keeping 1.484 until LazyLoading gets fixed) Oct 25, 2012 12:49:19 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Loading job some_job_name java.lang.NullPointerException at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:601) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:344) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:621) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:432) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:621) at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:574) at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:240) at java.util.AbstractMap$2$1.init(AbstractMap.java:378) at java.util.AbstractMap$2.iterator(AbstractMap.java:377) at hudson.util.RunList.iterator(RunList.java:103) at
[JIRA] (JENKINS-15439) Jenkins build records lazy-loading failed to load some of my jobs.
Jose Sa commented on JENKINS-15439 Jenkins build records lazy-loading failed to load some of my jobs. I'm still getting problems loading jobs after LazyLoading feature introduction. I've added my symptoms in JENKINS-15533 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-9688) Build runs on master without executor and get stuck
Jose Sa commented on JENKINS-9688 Build runs on master without executor and get stuck After several similar situations in the past weeks like this one where concurrent jobs using the same lock I think the problem may be mostly between chair and keyboard, but also due to lack of informative messages. Lets assume 3 jobs A, B and C using the same lock, the following timeline occurs: A is already running (so it has the lock) and we start B and C. B and C show in queue stating they are being blocked by A A finishes B and C already waited the 'delay' so they are ready to run, so they do run at the same time B gets the lock so it states it in the log is activelly running C on the other hand didn't get the lock, but is running anyway and showing no output that it is actively waiting for the lock Users panic when they see a job running for 2 days without any output in the log and cancel the C C get's inconsistent state and starts showing "null" instead of real dates Jenkins needs to be restarted to get rid of C because there is no way to kill it Also we observed that if we don't Cancel C eventually it starts executing normally when B finishes and showing it has acquired the lock in the log file. Bottom line the problem is lack of informative messages from the plugin to provide the proper feedback to users so they don't panic. Workaround: Revoke users permissions to Cancel builds that are using locks. 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-9688) Build runs on master without executor and get stuck
Jose Sa updated JENKINS-9688 Build runs on master without executor and get stuck Change By: Jose Sa (23/Sep/12 10:51 AM) Component/s: locks-and-latches 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-9688) Build runs on master without executor and get stuck
Jose Sa assigned JENKINS-9688 to stephenconnolly Build runs on master without executor and get stuck Change By: Jose Sa (23/Sep/12 10:53 AM) Assignee: stephenconnolly 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-14837) ldap email seems to perform a bind operation for each and every id that needs to be resolved
Jose Sa commented on JENKINS-14837 ldap email seems to perform a bind operation for each and every id that needs to be resolved Maybe this is not specific just to ldap email plugin as using the ldap authentication also allows to resolve email from username. We had one instance that there were so commiters since last failed build that a build that normally took 5 minutes was taking more than 20 because of constructing notification list from ldap. Mail information don't change that often, if they would be stored in the user information cached for at least a week it would greatly improve this. 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-13975) Promoted-builds not following jenkins access control policies
Jose Sa commented on JENKINS-13975 Promoted-builds not following jenkins access control policies Regarding "!anonymous" there is actually a special group in Matrix or Project-Matrix Auth Strategy called "authenticated" that matches any logged-in user as a counterpart of "anonymous" (not logged-in). But it seems you are trying to define yet another Auth layer in each Promote Action. Wich makes sense if you want to override or complement the Authorizations in upper levels (Job or Global). 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-13975) Promoted-builds not following jenkins access control policies
Jose Sa commented on JENKINS-13975 Promoted-builds not following jenkins access control policies I would expect the promoted builds which are inside the context of a specific job to follow the authorized defined on job level (or global if Project Matrix is not in use), either using the "Update" permission or a specific "Promote" permission (if it exists) 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-14560) Job names are only static string fields instead of auto-complete fields
Jose Sa created JENKINS-14560 Job names are only static string fields instead of auto-complete fields Issue Type: Improvement Assignee: Unassigned Components: promoted-builds Created: 24/Jul/12 7:45 PM Description: The fields referent for Job names in the Promote Plugin are not using the same component as other fields usually applicable to job naming that auto-complete the job names as you type. This makes it required to copy/paste the name from a different source. Environment: Jenkins promoted builds plugin v2.6.1 Project: Jenkins Priority: Major Reporter: Jose Sa 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-14561) Changing job names refered by Promoted builds plugin doesn't update when jobs are renamed
Jose Sa created JENKINS-14561 Changing job names refered by Promoted builds plugin doesnt update when jobs are renamed Issue Type: Bug Assignee: Unassigned Components: promoted-builds Created: 24/Jul/12 7:50 PM Description: We have some jobs configured with promotion processes dependent on downstream jobs to perform some actions when they succeed, however we noticed those actions not being taken after those downstream jobs were renamed. It was then verified that the definition of those job names in the Promotion section were not correctly updated as it happens in all other parts that refer to a job. Environment: Jenkins promoted builds plugin v2.6.1 Project: Jenkins Priority: Critical Reporter: Jose Sa 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-14406) It should be possible to set next build number from Command Line Interface
Jose Sa created JENKINS-14406 It should be possible to set next build number from Command Line Interface Issue Type: Bug Assignee: Dean Yu Components: next-build-number Created: 12/Jul/12 9:59 AM Description: The plugin next-build-number allows the override of the Next build number to a value greater than the current one from the Jenkins page, but it should also be possible to do this simple command from CLI interface. The CLI interface already allows to delete specific builds but not set the next build number. This would be very helpfull for automation cases where deploying jobs though command line interface based on templates for migration from other servers or build systems in order to provide continuation of build numbering on same components. Project: Jenkins Priority: Major Reporter: Jose Sa 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-14257) Saving job configuration looses slave defintion
Jose Sa created JENKINS-14257 Saving job configuration looses slave defintion Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 29/Jun/12 2:51 PM Description: In jenkins v1.472 when saving an existing job that had definitions of specific slaves where to run the job, it looses that definition. Had to revert back to previous version 1.467. Environment: Jenkins v1.472 Project: Jenkins Priority: Critical Reporter: Jose Sa 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-9688) Build runs on master without executor and get stuck
[ https://issues.jenkins-ci.org/browse/JENKINS-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163422#comment-163422 ] Jose Sa commented on JENKINS-9688: -- Even with delays it got stuck (maybe because I used exact same quiet period). Now I've configured different quiet periods to avoid this. Build runs on master without executor and get stuck --- Key: JENKINS-9688 URL: https://issues.jenkins-ci.org/browse/JENKINS-9688 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: protocol7b Attachments: job_time_null.png In the ASF Jenkins, we do not allow builds to run on master. Thus, we have set the number of executors on master to zero. Even so, one build recently (https://builds.apache.org/hudson/job/Axis2/774/) got assigned to run on master. The build is configured with a label to run on one of the slaves, but somehow Jenkins assigned it incorrectly. Running on master also meant it got stuck, presumably due to the lack of executors, without any way of stopping it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-2058) success even when archive artifact java error
[
https://issues.jenkins-ci.org/browse/JENKINS-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163385#comment-163385
]
Jose Sa commented on JENKINS-2058:
--
Here is another stack trace. This was running directly in the Master on a
Solaris 10 sparc with jdk1.6.0_19
{code}
Archiving artifacts
ERROR: Failed to archive artifacts: build.cs,CD_STAGE/*.nar*
hudson.util.IOException2: Failed to copy
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/workspace/build.cs,CD_STAGE/*.nar* to
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/builds/2012-05-31_12-11-08/archive
at hudson.FilePath$34.invoke(FilePath.java:1689)
at hudson.FilePath$34.invoke(FilePath.java:1656)
at hudson.FilePath.act(FilePath.java:832)
at hudson.FilePath.act(FilePath.java:814)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1656)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
at hudson.model.Run.run(Run.java:1438)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: Failed to copy
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/workspace/CD_STAGE/NAdM_2.0_OES_UPDATE-119-001.nar
to
/opt/hudson/jobs/NAdM2_SP1_Packages_LV1/builds/2012-05-31_12-11-08/archive/CD_STAGE/NAdM_2.0_OES_UPDATE-119-001.nar
due to Map failed
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:914)
at hudson.FilePath$34$1CopyImpl.doFileOperations(FilePath.java:1672)
at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:567)
at hudson.FilePath$34.invoke(FilePath.java:1686)
... 15 more
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:758)
at
sun.nio.ch.FileChannelImpl.transferFromFileChannel(FileChannelImpl.java:537)
at sun.nio.ch.FileChannelImpl.transferFrom(FileChannelImpl.java:600)
at
org.apache.tools.ant.util.ResourceUtils.copyResource(ResourceUtils.java:532)
at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:559)
at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:899)
... 18 more
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:755)
... 23 more
Triggering a new build of NAdM2_SP1_ISO_LV1 #27
Notifying upstream projects of job completion
Finished: SUCCESS
{code}
success even when archive artifact java error
-
Key: JENKINS-2058
URL: https://issues.jenkins-ci.org/browse/JENKINS-2058
Project: Jenkins
Issue Type: Bug
Components: master-slave
Affects Versions: current
Environment: Platform: All, OS: Solaris
Reporter: bll
Been having some troubles w/archive artifacts hanging from a linux master
(java
1.6) to solaris slave (java 1.5). Here's an instance where it actually got an
error, but reported success.
The hanging issue seems to be intermittent. It completed a job not long ago.
ERROR: Failed to archive artifacts: repoName, prevent-dev/version, build.log,
lastPush, prevent-dev/objs/**/*.tar.gz, prevent-dev/objs/**/*.map.gz,
prevent-dev/objs/**/cov-generate-hostid-*
hudson.util.IOException2: Failed to read the remote stream
/hudson_home/workspace/prevent-dev.solaris-x86/repoName, prevent-dev/version,
build.log, lastPush, prevent-dev/objs/**/*.tar.gz,
prevent-dev/objs/**/*.map.gz,
prevent-dev/objs/**/cov-generate-hostid-*
at hudson.FilePath.readFromTar(FilePath.java:922)
at hudson.FilePath.copyRecursiveTo(FilePath.java:846)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:78)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:309)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:297)
at hudson.model.Build$RunnerImpl.post2(Build.java:118)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:282)
at hudson.model.Run.run(Run.java:796)
at hudson.model.Build.run(Build.java:85)
at
[JIRA] (JENKINS-9688) Build runs on master without executor and get stuck
[ https://issues.jenkins-ci.org/browse/JENKINS-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Sa updated JENKINS-9688: - Attachment: job_time_null.png The problem still occurs in 1.458 see: !job_time_null.png! We have multiple jobs using the same lock representing a test environment, but without any quiet period. These jobs are not meant to run on master, but on a build slave, but in the build status it shows: Started 1 day 14 hr ago Build is being executed for null on master Maybe activating the default quiet period (30 seconds) will help in this situation. Build runs on master without executor and get stuck --- Key: JENKINS-9688 URL: https://issues.jenkins-ci.org/browse/JENKINS-9688 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: protocol7b Attachments: job_time_null.png In the ASF Jenkins, we do not allow builds to run on master. Thus, we have set the number of executors on master to zero. Even so, one build recently (https://builds.apache.org/hudson/job/Axis2/774/) got assigned to run on master. The build is configured with a label to run on one of the slaves, but somehow Jenkins assigned it incorrectly. Running on master also meant it got stuck, presumably due to the lack of executors, without any way of stopping it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13429) Nested views not showing up with just read perms for View
[ https://issues.jenkins-ci.org/browse/JENKINS-13429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162328#comment-162328 ] Jose Sa edited comment on JENKINS-13429 at 5/14/12 2:42 PM: Upgraded from 1.456 (which had nested views of nested views showing ok) to 1.462 and now it only shows the default All view and no nested views. Had to revert and will have to stick with 1.458 until nested tabs can be visible again with anonymous view.read permission is working. was (Author: josesa): Upgraded from 1.460 (which had nested views of nested views showing ok) to 1.462 and now it only shows the default All view and no nested views. Nested views not showing up with just read perms for View - Key: JENKINS-13429 URL: https://issues.jenkins-ci.org/browse/JENKINS-13429 Project: Jenkins Issue Type: Bug Components: nested-view Affects Versions: current Reporter: M S Assignee: Kohsuke Kawaguchi Labels: jenkins, plugin, views Jenkins 1.459 + Nested View Plugin 1.8 + Role-based Authorization Strategy 1.1.2 User has read permissions for View but Jenkins main page is missing Nested views (even if they have sub views with jobs). Adding configure perms for View results in Nested views showing up correctly. It looks like it's connected with: Added the View.READ permission to control visibility of views, and updated the default implementation to hide empty views. (issue 3681) -- 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-13429) Nested views not showing up with just read perms for View
[ https://issues.jenkins-ci.org/browse/JENKINS-13429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162328#comment-162328 ] Jose Sa edited comment on JENKINS-13429 at 5/14/12 2:43 PM: Upgraded from 1.456 (which had nested views of nested views showing ok) to 1.462 and now it only shows the default All view and no nested views. Had to revert and will have to stick with 1.458 until nested tabs can be visible again with anonymous view.read permission. was (Author: josesa): Upgraded from 1.456 (which had nested views of nested views showing ok) to 1.462 and now it only shows the default All view and no nested views. Had to revert and will have to stick with 1.458 until nested tabs can be visible again with anonymous view.read permission is working. Nested views not showing up with just read perms for View - Key: JENKINS-13429 URL: https://issues.jenkins-ci.org/browse/JENKINS-13429 Project: Jenkins Issue Type: Bug Components: nested-view Affects Versions: current Reporter: M S Assignee: Kohsuke Kawaguchi Labels: jenkins, plugin, views Jenkins 1.459 + Nested View Plugin 1.8 + Role-based Authorization Strategy 1.1.2 User has read permissions for View but Jenkins main page is missing Nested views (even if they have sub views with jobs). Adding configure perms for View results in Nested views showing up correctly. It looks like it's connected with: Added the View.READ permission to control visibility of views, and updated the default implementation to hide empty views. (issue 3681) -- 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-13429) Nested views not showing up with just read perms for View
[ https://issues.jenkins-ci.org/browse/JENKINS-13429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162328#comment-162328 ] Jose Sa commented on JENKINS-13429: --- Upgraded from 1.460 (which had nested views of nested views showing ok) to 1.462 and now it only shows the default All view and no nested views. Nested views not showing up with just read perms for View - Key: JENKINS-13429 URL: https://issues.jenkins-ci.org/browse/JENKINS-13429 Project: Jenkins Issue Type: Bug Components: nested-view Affects Versions: current Reporter: M S Assignee: Kohsuke Kawaguchi Labels: jenkins, plugin, views Jenkins 1.459 + Nested View Plugin 1.8 + Role-based Authorization Strategy 1.1.2 User has read permissions for View but Jenkins main page is missing Nested views (even if they have sub views with jobs). Adding configure perms for View results in Nested views showing up correctly. It looks like it's connected with: Added the View.READ permission to control visibility of views, and updated the default implementation to hide empty views. (issue 3681) -- 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
