[JIRA] (JENKINS-11225) Add aggregation and subview for multi-configuration projects
[ https://issues.jenkins-ci.org/browse/JENKINS-11225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163537#comment-163537 ] Ulli Hafner commented on JENKINS-11225: --- I hope that I have some spare time soon. Can someone please clarify what views are expected? Should there be an aggregation graph, what values should be shown, should there be only a details view, etc.? > Add aggregation and subview for multi-configuration projects > > > Key: JENKINS-11225 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11225 > Project: Jenkins > Issue Type: Improvement > Components: warnings >Affects Versions: current >Reporter: Jonas Oscarsson >Assignee: Ulli Hafner > > Issue added as a result of discussion from > https://issues.jenkins-ci.org/browse/JENKINS-6772. > In multi-configuration projects it would be preferable to have the warnings > plugin show a different view for each matrix element. On the main page for > the multi-configuration project we could have a aggregated view, showing the > number of warnings for each matrix element. > One specific case would be when having different compiler versions on one > axis, and operating systems on the other. It would then be interesting to see > warnings for the compiler gcc 4.4.2 compiling the project on RHEL4, as well > as the warnings for gcc 4.6.1 compiling the project on RHEL5. The aggregated > view would then show number of warnings for gcc 4.4.2/RHEL4 and gcc > 4.6.1/RHEL5 on the main page, and the subviews would show the actual warnings > for each combination of gcc and OS on the subpage. > Let me know if I need to clarify further. -- 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-14027) Can't run build flow configuration with parralell jobs
Luke Murray created JENKINS-14027:
-
Summary: Can't run build flow configuration with parralell jobs
Key: JENKINS-14027
URL: https://issues.jenkins-ci.org/browse/JENKINS-14027
Project: Jenkins
Issue Type: Bug
Components: build-flow
Environment: java.runtime.version 1.6.0_26-b03
os.name Windows 7
os.arch x86
Jenkins 1.467 (but tried version before that as well)
Reporter: Luke Murray
Assignee: Nicolas De Loof
Setting up a Build Flow project with the following configuration (tried maybe
different combinations of white space/newlines
parallel (
{
build("Master Wayfinder .NET")
},
{
build("Master Wayfinder Flex")
}
)
build("Master - Wayfinder Archive")
When the build starts I get this in the console...
parallel {
}
Trigger job Master - Wayfinder Archive
So it triggers the last build but doesn't trigger the builds before 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-6450) post-commit hook does no handle svn:externals
[ https://issues.jenkins-ci.org/browse/JENKINS-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163538#comment-163538 ] Klaus Azesberger commented on JENKINS-6450: --- we too have this issue, using a customized subversion-plugin based on 1.41-snapshot (fixed 2 issues with variables like $MY_PROJECT_SVN_URL in scm-url of projects) with jenkins 1.465 > post-commit hook does no handle svn:externals > - > > Key: JENKINS-6450 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6450 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: Windows, Hudson V1.356, Subversion Plug-in V1.17, "Poll > SCM" enabled and left empty >Reporter: Axel Heider > > I've set up a post-commit hook that send a post request with the changed > files (http://%HUDSON%/hudson/subversion/%UUID%/notifyCommit?rev=%REV%). It > works fine except for changes in directories or files referenced via > svn:externals. If something changes there, the project is no rebuild. -- 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-11257) Stopping a prent job doesn't stop the trgiggered child jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-11257 started by huybrechts. > Stopping a prent job doesn't stop the trgiggered child jobs > --- > > Key: JENKINS-11257 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11257 > Project: Jenkins > Issue Type: Bug > Components: parameterized-trigger >Affects Versions: current >Reporter: Nicolas Godelu >Assignee: huybrechts >Priority: Critical > > Assume you have a job A that launch a child Job B and that job A has to wait > Job B finished to continue its steps. > If you stopped job A while job B is processing, the job B isn't stopped. > It should be stopped. -- 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-6450) post-commit hook does no handle svn:externals
[ https://issues.jenkins-ci.org/browse/JENKINS-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163538#comment-163538 ] Klaus Azesberger edited comment on JENKINS-6450 at 6/6/12 9:14 AM: --- we too have a similar (probably the same) issue, using a customized subversion-plugin based on 1.41-snapshot (fixed 2 issues with variables like $MY_PROJECT_SVN_URL in scm-url of projects) with jenkins 1.465 we dont use post-commit-hook, we use simple scm-polling as build trigger. the svn polling protocol says "no changes", but when i manually trigger the build it updates changes "behind an svn external" correctly. was (Author: mcklaus): we too have this issue, using a customized subversion-plugin based on 1.41-snapshot (fixed 2 issues with variables like $MY_PROJECT_SVN_URL in scm-url of projects) with jenkins 1.465 > post-commit hook does no handle svn:externals > - > > Key: JENKINS-6450 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6450 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: Windows, Hudson V1.356, Subversion Plug-in V1.17, "Poll > SCM" enabled and left empty >Reporter: Axel Heider > > I've set up a post-commit hook that send a post request with the changed > files (http://%HUDSON%/hudson/subversion/%UUID%/notifyCommit?rev=%REV%). It > works fine except for changes in directories or files referenced via > svn:externals. If something changes there, the project is no rebuild. -- 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-14006) EnvInject stopped resolving environment variables in environment variables
[
https://issues.jenkins-ci.org/browse/JENKINS-14006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriele Giuseppini updated JENKINS-14006:
--
Attachment: config.xml
Configuration (of the promotion job) attached. Do you also need the
configuration of the job itself?
> EnvInject stopped resolving environment variables in environment variables
> --
>
> Key: JENKINS-14006
> URL: https://issues.jenkins-ci.org/browse/JENKINS-14006
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
> Environment: Jenkins 1.463, EnvInject 1.54 or 1.50
>Reporter: Gabriele Giuseppini
>Assignee: Gregory Boissinot
> Attachments: config.xml
>
>
> This looks like an exact regression to JENKINS-13183.
> We have a Promotion job that injects an env var whose value contains
> references to other env vars, read from a properties file:
> {code:xml}
>
>
>
> StageCraft.properties
>
> ReleaseDir=${ReleaseRoot}\${PROJECT_NAME}\${PROJECT_NAME}_${PROJECT_SHORT_VERSION}
> ReleaseDirTest=${env['PROJECT_SHORT_VERSION']}
>
>
>
> {code}
> (note we added a 'ReleaseDirTest' env var to also try the alternate env var
> reference syntax).
> EnvInject used to be fine with this, but after we did a few upgrades (to
> Jenkins itself and to the EnvInject plugin), it stopped working. Here's the
> output, together with a dump of the env vars injected in the build steps for
> diagnostics purposes:
> {code}
> Promoting ANONYMIZED #6
> [EnvInject] - Injecting environment variables from a build step.
> [EnvInject] - Injecting as environment variables the properties file path
> 'StageCraft.properties'
> [EnvInject] - Variables injected successfully.
> [EnvInject] - Injecting as environment variables the properties content
> ReleaseDir=${ReleaseRoot}\${PROJECT_NAME}\${PROJECT_NAME}_${PROJECT_SHORT_VERSION}
> ReleaseDirTest=${env['PROJECT_SHORT_VERSION']}
> [EnvInject] - Variables injected successfully.
> [EnvInject] - Unset unresolved 'ReleaseDir' variable.
> [EnvInject] - Unset unresolved 'ReleaseDirTest' variable.
> build org.jenkinsci.plugins.envinject.EnvInjectBuilder@53c01def SUCCESS
> [workspace] $ cmd /c call
> C:\Users\svc_ci\AppData\Local\Temp\hudson1186946183352599382.bat
> C:\jenkins\jobs\ANONYMIZED\workspace>SET
> ALLUSERSPROFILE=C:\ProgramData
> ...
> ProgramW6432=C:\Program Files
> PROJECT_FULL_VERSION=1.6.0.7
> PROJECT_NAME=ANONYMIZED
> PROJECT_SHORT_VERSION=1.6.0
> PROMOTED_ID=2012-06-01_15-42-27
> ...
> C:\jenkins\jobs\Cupid_1.6.x\workspace>exit 0
> {code}
--
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-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[
https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163540#comment-163540
]
stephenconnolly commented on JENKINS-13835:
---
This looks to be an encoding issue with your log messages on your subversion
server.
Log messages have always been required to be UTF-8. Only recent releases of
Subversion started enforcing it better at all layers. The SVN command line
client always handled this, but the lower level API's (and I suspect the SVNKit
library that Jenkins uses) did not so if you used a different client (i.e.
committing from TortoiseSVN or eclipse, etc) it was possible to get non-UTF-8
data into the repository.
You can use svnsync from SVN 1.7 to synch the existing repository to a new
repository using the --source-prop-encoding ARG option. This will convert the
existing revprops from the specified encoding to UTF-8 as part of synching to a
new repository. When the process is done, you can switch in the new repository
for the old one to fix your repository.
> upgrading Subversion Plugin to 1.40 totally ruined our CI server
>
>
> Key: JENKINS-13835
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
> Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39;
> Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16.
>Reporter: pancake
> Labels: plugin, subversion, windows
>
> Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
> resulted to {color:red}complete inability to perform a checkout. CI server is
> totally unusable now.{color}
> *Issue #1*
> After updating to Subversion Plugin to 1.40 (from 1.39) this exception
> started occurring _sometimes_ (various salves, various jobs):
> {quote}
> Checking out a fresh workspace because there's no workspace at
> C:\_JenkinsCI\workspace\XXX
> Cleaning local Directory .
> Checking out http://oursvnserver/svn/svnLatest/.../XXX
> A ...
> ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
> org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
> /svn/svnLatest/!svn/vcc/default failed
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
> at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
> at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
> at
> hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
> at
> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
> at hudson.remoting.UserRequest.p
[JIRA] (JENKINS-13969) Warnings Plugin does not recognize Eclipse Java warnings
[
https://issues.jenkins-ci.org/browse/JENKINS-13969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163541#comment-163541
]
Alexander Weickmann commented on JENKINS-13969:
---
Also not recognized:
[WARNING]
/media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core.test/src/com/faktorzehn/pa2msgpm/core/importer/PropertyImporterTest.java:[56,0]
private static final OperationResponseType ERROR_RESPONSE = new
OperationResponseType(1, "ERROR");
^^
The value of the field PropertyImporterTest.ERROR_RESPONSE is not used
1 problem (1 warning)
> Warnings Plugin does not recognize Eclipse Java warnings
>
>
> Key: JENKINS-13969
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13969
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
>Reporter: Alexander Weickmann
>Assignee: Ulli Hafner
>
> The following warnings are not detected by Jenkins, even tough they are
> written to console:
> {noformat}
> [INFO] Compiling 5 source files to
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/target/classes
> [WARNING]
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[369,0]
>
> private boolean compare(List rowTableValues, List
> allowedValues) {
>
>
> The method compare(List, List) from the type PmModelImporter
> is never used locally
> [WARNING]
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[391,0]
>
> private List getTableValues(PropertyRestrictionType
> restrictionType) {
>
> ^^^
> The method getTableValues(PropertyRestrictionType) from the type
> PmModelImporter is never used locally
> 2 problems (2 warnings)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13969) Warnings Plugin does not recognize Eclipse Java warnings
[
https://issues.jenkins-ci.org/browse/JENKINS-13969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163541#comment-163541
]
Alexander Weickmann edited comment on JENKINS-13969 at 6/6/12 9:52 AM:
---
Also not recognized:
{noformat}
[WARNING]
/media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core.test/src/com/faktorzehn/pa2msgpm/core/importer/PropertyImporterTest.java:[56,0]
private static final OperationResponseType ERROR_RESPONSE = new
OperationResponseType(1, "ERROR");
^^
The value of the field PropertyImporterTest.ERROR_RESPONSE is not used
1 problem (1 warning)
{noformat}
was (Author: alex):
Also not recognized:
[WARNING]
/media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core.test/src/com/faktorzehn/pa2msgpm/core/importer/PropertyImporterTest.java:[56,0]
private static final OperationResponseType ERROR_RESPONSE = new
OperationResponseType(1, "ERROR");
^^
The value of the field PropertyImporterTest.ERROR_RESPONSE is not used
1 problem (1 warning)
> Warnings Plugin does not recognize Eclipse Java warnings
>
>
> Key: JENKINS-13969
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13969
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
>Reporter: Alexander Weickmann
>Assignee: Ulli Hafner
>
> The following warnings are not detected by Jenkins, even tough they are
> written to console:
> {noformat}
> [INFO] Compiling 5 source files to
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/target/classes
> [WARNING]
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[369,0]
>
> private boolean compare(List rowTableValues, List
> allowedValues) {
>
>
> The method compare(List, List) from the type PmModelImporter
> is never used locally
> [WARNING]
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[391,0]
>
> private List getTableValues(PropertyRestrictionType
> restrictionType) {
>
> ^^^
> The method getTableValues(PropertyRestrictionType) from the type
> PmModelImporter is never used locally
> 2 problems (2 warnings)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13970) Build variable CC_BASELINE not populated with used baseline
[
https://issues.jenkins-ci.org/browse/JENKINS-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163542#comment-163542
]
Christian Wolfgang commented on JENKINS-13970:
--
Ok, I believe you do, because I found the bug.
I also fixed the issue with the missing baselines, which turned out to be
caused by a faulty merge. Stupid!
I am releasing version 1.1.1 right now, so I guess it's available later today.
> Build variable CC_BASELINE not populated with used baseline
> ---
>
> Key: JENKINS-13970
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase-ucm
>Affects Versions: current
> Environment: Microsoft Windows Server 2003, Standard x64 Edition,
> Service Pack 2
>Reporter: Tim Pillsbury
>Assignee: Christian Wolfgang
> Labels: clearcase, clearcase-ucm
>
> CCUCM says it is using the latest baseline, but the CC_BASELINE build
> variable is not always set to it.
> The problem seems to occur after "Updating view using all modules" if CCUCM
> finds activities and versions involved.
> {panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
> [CCUCM] Retrieved 28 baselines:
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT
> 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT
> 2012)
> [CCUCM] ...
> [CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT
> 2012)*_(n)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT
> 2012)
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)
> [CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
> [CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except
> CPF\workspace\view
> [CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Reusing view root
> [CCUCM] Determine if view tag exists
> [CCUCM] Reusing view tag
> [CCUCM] UUID resulted in
> CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Getting snapshotview
> [CCUCM] Rebasing development stream
> (CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent
> stream (WRKB_RLS_2012_06_00_ECM) Done
> [CCUCM] Updating view using all modules
> [CCUCM] _*Found 3 activities. 20 versions involved*_(i)
> {panel}
> But then Injected environment variable CC_BASELINE is incorrect
> {panel:title=Injected environment
> variables|titleBGColor=#E7D6C1|bgColor=#CE}
> |CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
> {panel}
--
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-13970) Build variable CC_BASELINE not populated with used baseline
[
https://issues.jenkins-ci.org/browse/JENKINS-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Wolfgang resolved JENKINS-13970.
--
Resolution: Fixed
Could you please verify my fix with your setup?
> Build variable CC_BASELINE not populated with used baseline
> ---
>
> Key: JENKINS-13970
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase-ucm
>Affects Versions: current
> Environment: Microsoft Windows Server 2003, Standard x64 Edition,
> Service Pack 2
>Reporter: Tim Pillsbury
>Assignee: Christian Wolfgang
> Labels: clearcase, clearcase-ucm
>
> CCUCM says it is using the latest baseline, but the CC_BASELINE build
> variable is not always set to it.
> The problem seems to occur after "Updating view using all modules" if CCUCM
> finds activities and versions involved.
> {panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
> [CCUCM] Retrieved 28 baselines:
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT
> 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT
> 2012)
> [CCUCM] ...
> [CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT
> 2012)*_(n)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT
> 2012)
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)
> [CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
> [CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except
> CPF\workspace\view
> [CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Reusing view root
> [CCUCM] Determine if view tag exists
> [CCUCM] Reusing view tag
> [CCUCM] UUID resulted in
> CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Getting snapshotview
> [CCUCM] Rebasing development stream
> (CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent
> stream (WRKB_RLS_2012_06_00_ECM) Done
> [CCUCM] Updating view using all modules
> [CCUCM] _*Found 3 activities. 20 versions involved*_(i)
> {panel}
> But then Injected environment variable CC_BASELINE is incorrect
> {panel:title=Injected environment
> variables|titleBGColor=#E7D6C1|bgColor=#CE}
> |CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
> {panel}
--
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-2548) Node does not come back online after disk space cleared
[ https://issues.jenkins-ci.org/browse/JENKINS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163544#comment-163544 ] kolos commented on JENKINS-2548: Hello, I do not mean to moan, but I've been trying to get my Jenkins nodes to come back online in the last 30-40 mins and it doesn't matter if I click the button 'back online' or restart Jenkins itself, it doesn't make a difference. :( One node just on its own managed to come back online, not sure how/why. I'm a bit surprised that this isn't biting many more people. May I suggest increasing the priority of this issue? Kolos > Node does not come back online after disk space cleared > --- > > Key: JENKINS-2548 > URL: https://issues.jenkins-ci.org/browse/JENKINS-2548 > Project: Jenkins > Issue Type: Bug > Components: master-slave >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: manderson23 >Assignee: abayer > > We are using Hudson as a single master server and had it go offline due to > less > than 1GB disk space being enabled. > After we clear some disk space Hudson does not come back online until we > restart > the servlet container. Could it not detect that there is enough disk space > available and come back online automatically? -- 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-9309) sloccount trend report only works up to last failed build
[ https://issues.jenkins-ci.org/browse/JENKINS-9309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163545#comment-163545 ] sogabe commented on JENKINS-9309: - @kbrandt I tried your pull request. It seemed OK but clicking a failed build cause exception. See attached log and screenshot. > sloccount trend report only works up to last failed build > - > > Key: JENKINS-9309 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9309 > Project: Jenkins > Issue Type: Bug > Components: sloccount >Reporter: Johannes Wienke >Assignee: Karsten Brandt > Attachments: sloccount.log, sloccount_build_page.png > > > The rend report generated by the sloccount plugin is destroyed by failing > builds. The trend report only displays the results up to the last failing > build. This reduces the usefulness of the report as no general view over the > whole project life time is possible. -- 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-9309) sloccount trend report only works up to last failed build
[ https://issues.jenkins-ci.org/browse/JENKINS-9309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sogabe updated JENKINS-9309: Attachment: sloccount_build_page.png sloccount.log > sloccount trend report only works up to last failed build > - > > Key: JENKINS-9309 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9309 > Project: Jenkins > Issue Type: Bug > Components: sloccount >Reporter: Johannes Wienke >Assignee: Karsten Brandt > Attachments: sloccount.log, sloccount_build_page.png > > > The rend report generated by the sloccount plugin is destroyed by failing > builds. The trend report only displays the results up to the last failing > build. This reduces the usefulness of the report as no general view over the > whole project life time is possible. -- 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-2548) Node does not come back online after disk space cleared
[ https://issues.jenkins-ci.org/browse/JENKINS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163546#comment-163546 ] kolos commented on JENKINS-2548: Ah, ok, it looks like I need to do these to bring a node back online: In order: # clean up disk space # restart Jenkins itself # mark the offline node as being back online Kolos > Node does not come back online after disk space cleared > --- > > Key: JENKINS-2548 > URL: https://issues.jenkins-ci.org/browse/JENKINS-2548 > Project: Jenkins > Issue Type: Bug > Components: master-slave >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: manderson23 >Assignee: abayer > > We are using Hudson as a single master server and had it go offline due to > less > than 1GB disk space being enabled. > After we clear some disk space Hudson does not come back online until we > restart > the servlet container. Could it not detect that there is enough disk space > available and come back online automatically? -- 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-14003) Starteam plugin takes a very long time for code check out
[ https://issues.jenkins-ci.org/browse/JENKINS-14003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163547#comment-163547 ] K Ningthouj commented on JENKINS-14003: --- Hi jan_ruzicka, Thanks for the reply. Please find my response inline: Can the problem be reproduced easily? -- Yes Does it show on all projects every time or are some projects slowed down more then others? -- Yes Does the checkout take same time as checking out clean project using command line? -- No, the command line takes less time as compared to the plugin. The command line takes approximately about 10 minutes whereas the plugin takes a whopping 35 mins for a clean checkout. Is the slowdown observed on a master or a slave? -- No slave configuration is done. Does it make a difference? -- N/A What setup is used? -- We are setting it up as a windows service. What version of server and client are in play? -- Jenkins Server version 1.447. No client is used. What configuration? -- Starteam plugin version 0.6.7 Are cache agents used? (mentioned in JENKINS-13398 ) -- No What parameters are passed to StarTeam command to speed up checkout? -- NCO stands for “needs check-out.” Sample command line below: stcmd co -p "" -is -F NCO -rp "C:\Jenkins\Workspace\MyProject" "*" > Starteam plugin takes a very long time for code check out > - > > Key: JENKINS-14003 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14003 > Project: Jenkins > Issue Type: Improvement > Components: starteam >Reporter: K Ningthouj >Assignee: jan_ruzicka > > We are using Starteam plugin with Jenkins for our project. When we perform > check-outs, it takes a very long time unlike when we run the starteam command > line using stcmd which is pretty fast. Is there any possibility in the > current plug-in that provides a way that we can pass a parameter just like > the starteam command line to speed up the checkout process? -- 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-12339) crowd2 plugin: misspelling in error message
[ https://issues.jenkins-ci.org/browse/JENKINS-12339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163548#comment-163548 ] SCM/JIRA link daemon commented on JENKINS-12339: Code changed in jenkins User: Thorsten Heit Path: src/main/resources/de/theit/jenkins/crowd/ErrorMessages.properties http://jenkins-ci.org/commit/crowd2-plugin/e6479b4f777b391fab37aab9e8af59d98d10bf91 Log: Fix for issue JENKINS-12339: crowd2 plugin: misspelling in error message > crowd2 plugin: misspelling in error message > --- > > Key: JENKINS-12339 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12339 > Project: Jenkins > Issue Type: Bug > Components: crowd2 >Reporter: Jason Sachs >Assignee: Thorsten Heit >Priority: Trivial > > Under Jenkins configure, enable security, Security Realm "Crowd 2", if the > group name doesn't exist, you get this message: > The group 'jenkins-users' odes not exist or is not active. > when it should say this message > The group 'jenkins-users' does not exist or is not active. -- 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-13515) Copy failed on windows machine because of timestamp
[ https://issues.jenkins-ci.org/browse/JENKINS-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163549#comment-163549 ] Cees Bos commented on JENKINS-13515: Same holds for us. Copy was done from a linux master to a windows slave. We had to revert the plugin to 1.21. > Copy failed on windows machine because of timestamp > --- > > Key: JENKINS-13515 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13515 > Project: Jenkins > Issue Type: Bug > Components: copyartifact > Environment: Jenkins ver. 1.460, debian master. > XP slave. >Reporter: Bertrand Latinville >Assignee: Kohsuke Kawaguchi > > After upgrading Copy artifacts plugin to 1.22 I have some problems of copy on > a windows XP slave. > Downgrading to 1.21 solves the problem. > This is the same issue as https://issues.jenkins-ci.org/browse/JENKINS-11073 > ERROR: Failed to copy artifacts from job with filter: **/* > hudson.util.IOException2: Failed to copy > /var/lib/jenkins/jobs/(filepath).html to C:\jenkins\workspace\(filepath).html > at > hudson.plugins.copyartifact.FingerprintingCopyMethod.copyOne(FingerprintingCopyMethod.java:91) > at > hudson.plugins.copyartifact.FingerprintingCopyMethod.copyAll(FingerprintingCopyMethod.java:63) > at > hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:243) > at > hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:211) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705) > at hudson.model.Build$RunnerImpl.build(Build.java:178) > at hudson.model.Build$RunnerImpl.doRun(Build.java:139) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) > at hudson.model.Run.run(Run.java:1421) > 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: hudson.util.IOException2: remote file operation failed: > C:\jenkins\workspace\(filepath).html at > hudson.remoting.Channel@2b0857d2:build-w7 > at hudson.FilePath.act(FilePath.java:828) > at hudson.FilePath.act(FilePath.java:814) > at hudson.FilePath.touch(FilePath.java:1160) > at > hudson.plugins.copyartifact.FingerprintingCopyMethod.copyOne(FingerprintingCopyMethod.java:79) > ... 12 more > Caused by: java.io.IOException: Failed to set the timestamp of > C:\jenkins\workspace\(filepath).html to 1334755712000 > at hudson.FilePath$19.invoke(FilePath.java:1166) > at hudson.FilePath$19.invoke(FilePath.java:1160) > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:287) > at > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at hudson.remoting.Engine$1$1.run(Engine.java:60) > at java.lang.Thread.run(Unknown Source) > Build step 'Copy artifacts from another project' marked build as failure -- 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-14028) Embedding .mobileprovision for IPA build doesn't work XCode 4.2 (4C199)
Steve Longhurst created JENKINS-14028:
-
Summary: Embedding .mobileprovision for IPA build doesn't work
XCode 4.2 (4C199)
Key: JENKINS-14028
URL: https://issues.jenkins-ci.org/browse/JENKINS-14028
Project: Jenkins
Issue Type: Bug
Components: xcode
Affects Versions: current
Environment: XCode 4.2 (4C199)
MacOS 10.6.8 (Snow Leopard)
Jenkins 1.467
Reporter: Steve Longhurst
I noticed that specifying a path to my .mobileprovision in the XCodeBuild
configuration for a project, whilst using the "Build IPA" setting doesn't
actually embed that provision in the final IPA file.
On the xcrun command line, if you specify --embed /path/to/my.mobileprovision,
the command doesn't seem to actually embed the provision unless you also
specify --sign "iPhone Distribution: My Name" at the same time. When you
specify --sign, you get a verbose message like so:
### Embedding '/Jenkins/workspace/my-ios-project/my.mobileprovision'
Making use of the additional codeSigningIdentity parameter (added in the latest
Github sourcr), adding the following lines to XCodeBuilder.java:468 in the
1.3.2-SNAPSHOT src (just after the --embed output) fix the problem:
if (!StringUtils.isEmpty(codeSigningIdentity)) {
packageCommandLine.add("--sign");
packageCommandLine.add(codeSigningIdentity);
}
--
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-14028) Embedding .mobileprovision for IPA build doesn't work XCode 4.2 (4C199)
[
https://issues.jenkins-ci.org/browse/JENKINS-14028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Longhurst updated JENKINS-14028:
--
Description:
I noticed that specifying a path to my .mobileprovision in the XCodeBuild
configuration for a project, whilst using the "Build IPA" setting doesn't
actually embed that provision in the final IPA file.
On the xcrun command line, if you specify --embed /path/to/my.mobileprovision,
the command doesn't seem to actually embed the provision unless you also
specify --sign "iPhone Distribution: My Name" at the same time. When you
specify --sign, you get a verbose message like so:
{noformat}
### Embedding '/Jenkins/workspace/my-ios-project/my.mobileprovision'
{noformat}
Making use of the additional codeSigningIdentity parameter (added in the latest
Github sourcr), adding the following lines to XCodeBuilder.java:468 in the
1.3.2-SNAPSHOT src (just after the --embed output) fix the problem:
{code}
if (!StringUtils.isEmpty(codeSigningIdentity)) {
packageCommandLine.add("--sign");
packageCommandLine.add(codeSigningIdentity);
}
{code}
was:
I noticed that specifying a path to my .mobileprovision in the XCodeBuild
configuration for a project, whilst using the "Build IPA" setting doesn't
actually embed that provision in the final IPA file.
On the xcrun command line, if you specify --embed /path/to/my.mobileprovision,
the command doesn't seem to actually embed the provision unless you also
specify --sign "iPhone Distribution: My Name" at the same time. When you
specify --sign, you get a verbose message like so:
### Embedding '/Jenkins/workspace/my-ios-project/my.mobileprovision'
Making use of the additional codeSigningIdentity parameter (added in the latest
Github sourcr), adding the following lines to XCodeBuilder.java:468 in the
1.3.2-SNAPSHOT src (just after the --embed output) fix the problem:
if (!StringUtils.isEmpty(codeSigningIdentity)) {
packageCommandLine.add("--sign");
packageCommandLine.add(codeSigningIdentity);
}
> Embedding .mobileprovision for IPA build doesn't work XCode 4.2 (4C199)
> ---
>
> Key: JENKINS-14028
> URL: https://issues.jenkins-ci.org/browse/JENKINS-14028
> Project: Jenkins
> Issue Type: Bug
> Components: xcode
>Affects Versions: current
> Environment: XCode 4.2 (4C199)
> MacOS 10.6.8 (Snow Leopard)
> Jenkins 1.467
>Reporter: Steve Longhurst
>
> I noticed that specifying a path to my .mobileprovision in the XCodeBuild
> configuration for a project, whilst using the "Build IPA" setting doesn't
> actually embed that provision in the final IPA file.
> On the xcrun command line, if you specify --embed
> /path/to/my.mobileprovision, the command doesn't seem to actually embed the
> provision unless you also specify --sign "iPhone Distribution: My Name" at
> the same time. When you specify --sign, you get a verbose message like so:
> {noformat}
> ### Embedding '/Jenkins/workspace/my-ios-project/my.mobileprovision'
> {noformat}
> Making use of the additional codeSigningIdentity parameter (added in the
> latest Github sourcr), adding the following lines to XCodeBuilder.java:468 in
> the 1.3.2-SNAPSHOT src (just after the --embed output) fix the problem:
> {code}
> if (!StringUtils.isEmpty(codeSigningIdentity)) {
>packageCommandLine.add("--sign");
>packageCommandLine.add(codeSigningIdentity);
> }
> {code}
--
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-13609) Lost of the latest build after jenkins restart
[ https://issues.jenkins-ci.org/browse/JENKINS-13609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163550#comment-163550 ] Cees Bos commented on JENKINS-13609: We have a similar issue, that after a restart some jobs do not have history at all anymore But on filesystem of the master there is still a lot of history. For a particular job is has 30 old builds on disk on the master, but in the view there is nothing anymore. > Lost of the latest build after jenkins restart > -- > > Key: JENKINS-13609 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13609 > Project: Jenkins > Issue Type: Bug > Components: build-publisher, core >Reporter: stibbons >Assignee: vjuranek > Attachments: jenkins.log > > > Hello > I have a recuring problem since some weeks, I though this was coming from > me... so here is the description: > - I have a build which produce junit files to be parsed and included in the > results > - each night this build run and generates a new build number + artifacts + > HTML report + junit report > - after the build, its number appears in the build history, correctly. > However, sometimes, after a jenkins restart, the latest build (262) has > disapeared from the build history, so the first one is the previous (261)! > Even the artifact published are from the previous build (261). > If I go in the workspace I can see files created by the latest build. > When I start a new build, the build number is as expected (263). > It's like if the build enumeration system skips the latest build. > I join the jenkins log in attachment. As you can see the > "OCHD_Inc_Build_HEAD_05_Non_Reg_Tests_RHES5_64_Atomix_Dual_Channels" jobs > starts enumerating jobs by #261 while the job #262 has been ignored (the > directory > .../OCHD_Inc_Build_HEAD_05_Non_Reg_Tests_RHES5_64_Atomix_Dual_Channels/builds/262 > exists... However, lastStable and lastSucessful has not been updated. > nextBuildNumber is well set to 263). > Thanks, > G. -- 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-7978) Variable substitution in Buckminster script file not respected
[
https://issues.jenkins-ci.org/browse/JENKINS-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163551#comment-163551
]
aewallace commented on JENKINS-7978:
To add to the above, I've also recently attempted to use a Buckminster script
file again with the latest Jenkins Buckminster plugin (1.10) after previously
using the normal entry of Buckminster command in my build configuration. I am
still finding that environment variables are not picked up, even using the
${env_var:WORKSPACE} nomenclature as described above.
The first entry in my script file is:
importtargetdefinition --active ${env_var:WORKSPACE}/path/subpath/bucky.target
The build always fails as the ${env_var:WORKSPACE} is never expanded (always a
blank string) and hence the full path that I need cannot be used as I just end
up with "/path/subpath/bucky.target" Am I missing something? Buckminster
version is 3.7.
> Variable substitution in Buckminster script file not respected
> --
>
> Key: JENKINS-7978
> URL: https://issues.jenkins-ci.org/browse/JENKINS-7978
> Project: Jenkins
> Issue Type: Bug
> Components: buckminster
>Affects Versions: current
> Environment: Windows7
>Reporter: aewallace
>Assignee: jutzig
>
> When I used a script file including my Buckminster commands instead of
> entering the commands directly into the Buckminster command text area
> variable substitution does not appear to be respected.
> Thus, if I use something like ${WORKSPACE}/pathToSomething in the command
> enterted directly in the Buckminster text area , then the ${WORKSPACE}
> variable is substituted correctly to the Hudson workspace for the current
> job. However, if I use the same variable within my Buckminster script file,
> then a blank string is substituted instead when the command is run.
--
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-11225) Add aggregation and subview for multi-configuration projects
[ https://issues.jenkins-ci.org/browse/JENKINS-11225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163552#comment-163552 ] bnovc commented on JENKINS-11225: - I would be happy if the normal warnings plugin output was visible for each configuration when you click on them. In my case I don't care about getting any aggregation/totals, because there are going to be a lot of duplicates. > Add aggregation and subview for multi-configuration projects > > > Key: JENKINS-11225 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11225 > Project: Jenkins > Issue Type: Improvement > Components: warnings >Affects Versions: current >Reporter: Jonas Oscarsson >Assignee: Ulli Hafner > > Issue added as a result of discussion from > https://issues.jenkins-ci.org/browse/JENKINS-6772. > In multi-configuration projects it would be preferable to have the warnings > plugin show a different view for each matrix element. On the main page for > the multi-configuration project we could have a aggregated view, showing the > number of warnings for each matrix element. > One specific case would be when having different compiler versions on one > axis, and operating systems on the other. It would then be interesting to see > warnings for the compiler gcc 4.4.2 compiling the project on RHEL4, as well > as the warnings for gcc 4.6.1 compiling the project on RHEL5. The aggregated > view would then show number of warnings for gcc 4.4.2/RHEL4 and gcc > 4.6.1/RHEL5 on the main page, and the subviews would show the actual warnings > for each combination of gcc and OS on the subpage. > Let me know if I need to clarify further. -- 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-13969) Warnings Plugin does not recognize Eclipse Java warnings
[
https://issues.jenkins-ci.org/browse/JENKINS-13969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JENKINS-13969 started by Ulli Hafner.
> Warnings Plugin does not recognize Eclipse Java warnings
>
>
> Key: JENKINS-13969
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13969
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
>Reporter: Alexander Weickmann
>Assignee: Ulli Hafner
>
> The following warnings are not detected by Jenkins, even tough they are
> written to console:
> {noformat}
> [INFO] Compiling 5 source files to
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/target/classes
> [WARNING]
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[369,0]
>
> private boolean compare(List rowTableValues, List
> allowedValues) {
>
>
> The method compare(List, List) from the type PmModelImporter
> is never used locally
> [WARNING]
> /media/ssd/multi-x-processor/workspace/msgPM_Access/com.faktorzehn.pa2msgpm.core/src/com/faktorzehn/pa2msgpm/core/loader/PmModelImporter.java:[391,0]
>
> private List getTableValues(PropertyRestrictionType
> restrictionType) {
>
> ^^^
> The method getTableValues(PropertyRestrictionType) from the type
> PmModelImporter is never used locally
> 2 problems (2 warnings)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11225) Add aggregation and subview for multi-configuration projects
[ https://issues.jenkins-ci.org/browse/JENKINS-11225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163553#comment-163553 ] Roland Schulz commented on JENKINS-11225: - I think the view for unit tests is very good for multi-configurations and it would be great if that could be similar for warnings. For an example how the unit test view look see: http://jenkins.gromacs.org/job/Gromacs_Gerrit_4_6/727/testReport/ . I think this view lets one quickly see which configuration has test failures and which test failures are duplicates and which ones are unique and require one to look at in detail. In comparison for warnings one has to click on each configuration to see whether a configuration has any warnings and if so whether they are different from those of different configuration. @bnoc: If I click on a configuration, I do get the warnings for that configuration shown (e.g. http://jenkins.gromacs.org/job/Gromacs_Gerrit_master/653/OPTIONS=Compiler=gcc%20CompilerVersion=4.1%20GMX_DOUBLE=ON%20GMX_OPENMP=OFF%20GMX_GSL=on%20host=master,label=master/). You might have some additional problem with your setup. > Add aggregation and subview for multi-configuration projects > > > Key: JENKINS-11225 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11225 > Project: Jenkins > Issue Type: Improvement > Components: warnings >Affects Versions: current >Reporter: Jonas Oscarsson >Assignee: Ulli Hafner > > Issue added as a result of discussion from > https://issues.jenkins-ci.org/browse/JENKINS-6772. > In multi-configuration projects it would be preferable to have the warnings > plugin show a different view for each matrix element. On the main page for > the multi-configuration project we could have a aggregated view, showing the > number of warnings for each matrix element. > One specific case would be when having different compiler versions on one > axis, and operating systems on the other. It would then be interesting to see > warnings for the compiler gcc 4.4.2 compiling the project on RHEL4, as well > as the warnings for gcc 4.6.1 compiling the project on RHEL5. The aggregated > view would then show number of warnings for gcc 4.4.2/RHEL4 and gcc > 4.6.1/RHEL5 on the main page, and the subviews would show the actual warnings > for each combination of gcc and OS on the subpage. > Let me know if I need to clarify further. -- 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
Deploying War File to Tomact Server
I installed deploy to container plugin to deploy generated war file(by ant) to Tomcat It gives explanation: War files to deploy. But I didn't achieve to give the set the war file path. build.xml is under the project directory. It generates war file and puts it to a different directory. How can I set war file path? When I give full directory path it gives error to give ant style globs and I didn't get any exception and error from jenkins console I checked server deployed path but my war file not deployed . Can anyone help me for the configuration? Thanks Regards.. -- View this message in context: http://jenkins.361315.n4.nabble.com/Deploying-War-File-to-Tomact-Server-tp4630728.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-13827) Getting OutOfMemoryError after Jenkins has been running for several days
[ https://issues.jenkins-ci.org/browse/JENKINS-13827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163554#comment-163554 ] Ed Palazzo commented on JENKINS-13827: -- Happened again today. > Getting OutOfMemoryError after Jenkins has been running for several days > > > Key: JENKINS-13827 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13827 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Jenkins 1.458 > Red Hat Enterprise Linux ES release 4 (Nahant Update 4) > 32-bit hardware and OS > java 1.6.0_17 > perforce plugin 1.3.8 > 8 virtual CPUs > 16 GB total available memory on the system >Reporter: Ed Palazzo > > After running from anywhere from one to two weeks, Jenkins will appear to be > frozen. Examination of the logs shows the following error: > java.lang.OutOfMemoryError: GC overhead limit exceeded > I've done numerous stack dumps, and it is fairly inconsistent as to what is > happening when the error occurs. This last time I did a heap dump per the > instructions on this page: > https://wiki.jenkins-ci.org/display/JENKINS/I%27m+getting+OutOfMemoryError > The heap is available for download via FTP here: > ftp://Jenkins:maqla...@kpsg.kofax.com/heap.bin.gz > It's about 300M compressed (~1.6GB uncompressed). I had a hard time running > jhat against the heap -- maybe you'll have more luck. > I should let you know that I have 565 jobs (all modules of different > branches) configured on this system. I have one slave running builds, with > another two machines on the way. > Let me know what else I can provide to help debug. -- 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-13970) Build variable CC_BASELINE not populated with used baseline
[
https://issues.jenkins-ci.org/browse/JENKINS-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163555#comment-163555
]
Tim Pillsbury commented on JENKINS-13970:
-
Thanks so much Christian!
I will test version 1.1.1 as soon as I see it in my Update Center and will post
the results here.
Really appreciate your help.
> Build variable CC_BASELINE not populated with used baseline
> ---
>
> Key: JENKINS-13970
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase-ucm
>Affects Versions: current
> Environment: Microsoft Windows Server 2003, Standard x64 Edition,
> Service Pack 2
>Reporter: Tim Pillsbury
>Assignee: Christian Wolfgang
> Labels: clearcase, clearcase-ucm
>
> CCUCM says it is using the latest baseline, but the CC_BASELINE build
> variable is not always set to it.
> The problem seems to occur after "Updating view using all modules" if CCUCM
> finds activities and versions involved.
> {panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
> [CCUCM] Retrieved 28 baselines:
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT
> 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT
> 2012)
> [CCUCM] ...
> [CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT
> 2012)*_(n)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT
> 2012)
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)
> [CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
> [CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except
> CPF\workspace\view
> [CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Reusing view root
> [CCUCM] Determine if view tag exists
> [CCUCM] Reusing view tag
> [CCUCM] UUID resulted in
> CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Getting snapshotview
> [CCUCM] Rebasing development stream
> (CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent
> stream (WRKB_RLS_2012_06_00_ECM) Done
> [CCUCM] Updating view using all modules
> [CCUCM] _*Found 3 activities. 20 versions involved*_(i)
> {panel}
> But then Injected environment variable CC_BASELINE is incorrect
> {panel:title=Injected environment
> variables|titleBGColor=#E7D6C1|bgColor=#CE}
> |CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
> {panel}
--
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-14029) New color "terminals" breaks old logs
Christian Höltje created JENKINS-14029: -- Summary: New color "terminals" breaks old logs Key: JENKINS-14029 URL: https://issues.jenkins-ci.org/browse/JENKINS-14029 Project: Jenkins Issue Type: Bug Components: ansicolor Reporter: Christian Höltje When viewing logs from builds from *before* the latest ansicolor (the one where you can configure colors) you get this error in the logs: Jun 06, 2012 10:19:55 AM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.writeLogTo(offset,output). Reason: java.lang.NullPointerException java.lang.NullPointerException at hudson.plugins.ansicolor.AnsiHtmlOutputStream.processSetForegroundColor(AnsiHtmlOutputStream.java:137) at org.fusesource.jansi.AnsiOutputStream.processEscapeCommand(AnsiOutputStream.java:275) at org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:125) at hudson.plugins.ansicolor.AnsiHtmlOutputStream.write(AnsiHtmlOutputStream.java:91) at java.io.FilterOutputStream.write(Unknown Source) at hudson.plugins.ansicolor.AnsiHtmlOutputStream.writeLine(AnsiHtmlOutputStream.java:96) at hudson.plugins.ansicolor.AnsiColorizer.eol(AnsiColorizer.java:51) at hudson.plugins.ansicolor.AnsiColorNote.colorize(AnsiColorNote.java:79) at hudson.plugins.ansicolor.AnsiColorNote.annotate(AnsiColorNote.java:58) at hudson.console.ConsoleAnnotationOutputStream$1.annotate(ConsoleAnnotationOutputStream.java:115) at hudson.console.ConsoleAnnotator$1Aggregator.annotate(ConsoleAnnotator.java:111) at hudson.console.ConsoleAnnotationOutputStream.eol(ConsoleAnnotationOutputStream.java:145) at hudson.console.LineTransformationOutputStream.eol(LineTransformationOutputStream.java:60) at hudson.console.LineTransformationOutputStream.write(LineTransformationOutputStream.java:56) at hudson.console.LineTransformationOutputStream.write(LineTransformationOutputStream.java:74) at org.apache.commons.io.output.ProxyOutputStream.write(ProxyOutputStream.java:70) at org.apache.commons.io.output.CountingOutputStream.write(CountingOutputStream.java:71) at org.kohsuke.stapler.framework.io.LargeText.writeLogTo(LargeText.java:172) at hudson.console.AnnotatedLargeText.writeHtmlTo(AnnotatedLargeText.java:158) at hudson.model.Run.writeLogTo(Run.java:1172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) at org.apache.commons.jelly.parser.EscapingExpression.evaluate(EscapingExpression.java:24) at org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:66) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.WhitespaceTag.doTag(WhitespaceTag.java:48) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:41) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) 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:270) at org.apache.commons
[JIRA] (JENKINS-14029) New color "terminals" breaks old logs
[ https://issues.jenkins-ci.org/browse/JENKINS-14029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163556#comment-163556 ] Christian Höltje commented on JENKINS-14029: I also opened this at: https://github.com/dblock/jenkins-ansicolor-plugin/issues/10 > New color "terminals" breaks old logs > - > > Key: JENKINS-14029 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14029 > Project: Jenkins > Issue Type: Bug > Components: ansicolor >Reporter: Christian Höltje > > When viewing logs from builds from *before* the latest ansicolor (the one > where you can configure colors) you get this error in the logs: > Jun 06, 2012 10:19:55 AM hudson.ExpressionFactory2$JexlExpression evaluate > WARNING: Caught exception evaluating: it.writeLogTo(offset,output). Reason: > java.lang.NullPointerException > java.lang.NullPointerException > at > hudson.plugins.ansicolor.AnsiHtmlOutputStream.processSetForegroundColor(AnsiHtmlOutputStream.java:137) > at > org.fusesource.jansi.AnsiOutputStream.processEscapeCommand(AnsiOutputStream.java:275) > at > org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:125) > at > hudson.plugins.ansicolor.AnsiHtmlOutputStream.write(AnsiHtmlOutputStream.java:91) > at java.io.FilterOutputStream.write(Unknown Source) > at > hudson.plugins.ansicolor.AnsiHtmlOutputStream.writeLine(AnsiHtmlOutputStream.java:96) > at hudson.plugins.ansicolor.AnsiColorizer.eol(AnsiColorizer.java:51) > at > hudson.plugins.ansicolor.AnsiColorNote.colorize(AnsiColorNote.java:79) > at > hudson.plugins.ansicolor.AnsiColorNote.annotate(AnsiColorNote.java:58) > at > hudson.console.ConsoleAnnotationOutputStream$1.annotate(ConsoleAnnotationOutputStream.java:115) > at > hudson.console.ConsoleAnnotator$1Aggregator.annotate(ConsoleAnnotator.java:111) > at > hudson.console.ConsoleAnnotationOutputStream.eol(ConsoleAnnotationOutputStream.java:145) > at > hudson.console.LineTransformationOutputStream.eol(LineTransformationOutputStream.java:60) > at > hudson.console.LineTransformationOutputStream.write(LineTransformationOutputStream.java:56) > at > hudson.console.LineTransformationOutputStream.write(LineTransformationOutputStream.java:74) > at > org.apache.commons.io.output.ProxyOutputStream.write(ProxyOutputStream.java:70) > at > org.apache.commons.io.output.CountingOutputStream.write(CountingOutputStream.java:71) > at > org.kohsuke.stapler.framework.io.LargeText.writeLogTo(LargeText.java:172) > at > hudson.console.AnnotatedLargeText.writeHtmlTo(AnnotatedLargeText.java:158) > at hudson.model.Run.writeLogTo(Run.java:1172) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258) > at > org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) > at > org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) > at > org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) > at > org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) > at > org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) > at > hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) > at > org.apache.commons.jelly.parser.EscapingExpression.evaluate(EscapingExpression.java:24) > at > org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:66) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at > org.apache.commons.jelly.tags.core.WhitespaceTag.doTag(WhitespaceTag.java:48) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at > org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:41) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > 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.
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
[ https://issues.jenkins-ci.org/browse/JENKINS-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eguess74 updated JENKINS-10025: --- Assignee: Gregory Boissinot (was: abayer) Thanks for the info, Timothy! Reassigned to Gregory. > Calling rebuildDependencyGraph() in cycle > - > > Key: JENKINS-10025 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10025 > Project: Jenkins > Issue Type: Bug > Components: ivy >Reporter: vjuranek >Assignee: Gregory Boissinot >Priority: Blocker > > There probably possible cycle call of rebuildDependencyGraph(), > Ivy calls > Hudson.getInstance().rebuildDependencyGraph(); > which starts following cycle: > getModuleDescriptor() -> recomputeModuleDescriptor() -> setModuleDescriptor() > -> hudson.model.Hudson.rebuildDependencyGraph() > which results into StackOverflowError, for whole exception, see > http://groups.google.com/group/jenkinsci-users/browse_thread/thread/3c6b67b448c98379# -- 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-14030) renaming a job does not preserve history
bnovc created JENKINS-14030: --- Summary: renaming a job does not preserve history Key: JENKINS-14030 URL: https://issues.jenkins-ci.org/browse/JENKINS-14030 Project: Jenkins Issue Type: Bug Components: core Reporter: bnovc When you rename a job, the history on the job is lost. I don't see any reason why this should happen and should at least be a choice. -- 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-12461) After 1.448 upgrade, jobs are missing
[ https://issues.jenkins-ci.org/browse/JENKINS-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163558#comment-163558 ] K C commented on JENKINS-12461: --- Is the solution to revert? We upgraded from hudson to jenkins and we have jobs missing. I really don't want to revert to hudson, is a older version. I upgraded to the latest jenkins we have missing jobs and we have builds that fail. > After 1.448 upgrade, jobs are missing > - > > Key: JENKINS-12461 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12461 > Project: Jenkins > Issue Type: Bug > Components: view-job-filters >Reporter: Chad Scribner >Assignee: Jacob Robertson > > After 1.448 upgrade, jobs are missing from the Jenkins web application (i.e. > they don't show up in the "All" view or any other views). Upon reverting > back to 1.447, the jobs are showing up again and seem to be unharmed. It > seems that the affected jobs were C++ ones that were perhaps utilizing the > SCONs and/or CPPunit plugins. -- 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-13959) StackOverflowException on Job Finish
[
https://issues.jenkins-ci.org/browse/JENKINS-13959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163559#comment-163559
]
Michael Clarke commented on JENKINS-13959:
--
Simon: I've been unable to replicate your issue so far, could you let me know
which plugins (including versions) you have installed? Also, do you have any
more lines from the stacktrace? Unfortunately it only currently shows up to a
point in the CVS plugin but I need to see what's calling it so I can work out
the call chain.
> StackOverflowException on Job Finish
>
>
> Key: JENKINS-13959
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13959
> Project: Jenkins
> Issue Type: Bug
> Components: cvs, notification
>Affects Versions: current
>Reporter: Simon Schlachter
> Attachments: example_fail_config.xml
>
>
> Since upgrading to jenkins 1.465 we get in some of our jobs the following
> stacktrace:
> {noformat}
> FATAL: null
> java.lang.StackOverflowError
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
> at
> java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
> at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
> at java.util.Calendar.updateTime(Calendar.java:2495)
> at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
> at java.util.Calendar.getMillisOf(Calendar.java:2512)
> at java.util.Calendar.equals(Calendar.java:1892)
> at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> ...
> {noformat}
> The Exception happens when the Job itself has finished and is about to report
> results to e-mail receivers.
> We were able to workaround the issue by removing the "send email
> notification" setting, storing the configuration and then re-add the
> notification setting, so perhaps it has something
[JIRA] (JENKINS-14003) Starteam plugin takes a very long time for code check out
[
https://issues.jenkins-ci.org/browse/JENKINS-14003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163560#comment-163560
]
jan_ruzicka commented on JENKINS-14003:
---
Thanks for getting back to me.
Sorry for not wording my questions properly.
Are some projects slowed down more then others?
I meant "Do you have different styles of projects? and Does it make
difference?"
Looking for indications as: Projects with just a few files are better then with
many. Big files slow down more then small files.
Clean project checkout takes 10 minutes? That is quite unusual by itself. What
kind of project are we talking about? Are there thousands of files and Gigs of
data?
By "What setup is used?" I meant StartTeam setup.
Example: Dedicated server for ST and dedicated server for ST Database.
Jenkins is on separate computer from ST server.
ST server network round-trips are min/avg/max/stddev = 0.522/0.718/1.097/0.137
ms
(ping from ST client machine to the ST server)
By "What version of server and client are in play?" I meant StartTeam server
version and StartTeam client version. Is it ST 2008, 2009, ...?
Output of stcmd would be helpful. First few lines are showing the executable
version information.
The command line parameters with filtering for NCO specifies only new and
changed files to be checked out
{{stcmd co -p "" -is -F NCO -rp "C:\Jenkins\Workspace\MyProject"
"*"}}
If you remove the contents of the local directory and try to check out the
project, how long does it take?
> Starteam plugin takes a very long time for code check out
> -
>
> Key: JENKINS-14003
> URL: https://issues.jenkins-ci.org/browse/JENKINS-14003
> Project: Jenkins
> Issue Type: Improvement
> Components: starteam
>Reporter: K Ningthouj
>Assignee: jan_ruzicka
>
> We are using Starteam plugin with Jenkins for our project. When we perform
> check-outs, it takes a very long time unlike when we run the starteam command
> line using stcmd which is pretty fast. Is there any possibility in the
> current plug-in that provides a way that we can pass a parameter just like
> the starteam command line to speed up the checkout process?
--
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-13715) User email suffixes are getting overwritten with the with the subversion repo UUID
[ https://issues.jenkins-ci.org/browse/JENKINS-13715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163561#comment-163561 ] David Pattison commented on JENKINS-13715: -- I have upgraded to Email-Ext 2.20. Still no luck > User email suffixes are getting overwritten with the with the subversion repo > UUID > -- > > Key: JENKINS-13715 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13715 > Project: Jenkins > Issue Type: Bug > Components: email-ext, subversion > Environment: Ubuntu 8.04 > Jenkins: 1.447.1 > Plugins: > javadoc 1.0 truefalse > maven-plugin 1.447.1 truefalse > ant 1.1 truefalse > analysis-core 1.18truefalse > pmd 3.14truefalse > cvs 1.6 truefalse > ci-game 1.18truefalse > instant-messaging 1.21truefalse > ircbot2.18truefalse > subversion1.23truetrue > ssh-slaves0.21truefalse > claim 1.7 truefalse > translation 1.8 truefalse > bugzilla 1.4 false false > WebSVN2 0.9 truefalse > email-ext 2.19truefalse > parameterized-trigger 2.12truefalse > git 1.1.12 truefalse > repository0.7 truefalse > bruceschneier 0.1 truefalse > global-build-stats1.0 truefalse > rebuild 1.9 truefalse > greenballs1.10truefalse > log-parser1.0.8 truefalse > schedule-failed-builds1.1 false false > analysis-collector1.12truefalse > radiatorviewplugin1.13truefalse > xunit 1.5 truefalse >Reporter: David Pattison > > Several users on the system can't get any build emails. > The email keep getting set to "davidp@046000e8-c612-472f-bb51-fe359d1450d5" > For certain users. > * This only happens to users who have configs set, in > $JENKINS_HOME/users/user-name.xml > * The number at the end is the Subversion UUID. > * Removing/deleting/modifying the user configs does not work. > This is very similar to the > https://issues.jenkins-ci.org/browse/JENKINS-11731, but only applies to some > users. -- 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-14027) Can't run build flow configuration with parralell jobs
[
https://issues.jenkins-ci.org/browse/JENKINS-14027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163562#comment-163562
]
Andreyev Melo commented on JENKINS-14027:
-
This happens to me too when using an old Jenkins version, even if I use plugin
version 0.3.
> Can't run build flow configuration with parralell jobs
> --
>
> Key: JENKINS-14027
> URL: https://issues.jenkins-ci.org/browse/JENKINS-14027
> Project: Jenkins
> Issue Type: Bug
> Components: build-flow
> Environment: java.runtime.version 1.6.0_26-b03
> os.name Windows 7
> os.arch x86
> Jenkins 1.467 (but tried version before that as well)
>Reporter: Luke Murray
>Assignee: Nicolas De Loof
>
> Setting up a Build Flow project with the following configuration (tried maybe
> different combinations of white space/newlines
> parallel (
> {
> build("Master Wayfinder .NET")
> },
> {
> build("Master Wayfinder Flex")
> }
> )
> build("Master - Wayfinder Archive")
> When the build starts I get this in the console...
> parallel {
> }
> Trigger job Master - Wayfinder Archive
> So it triggers the last build but doesn't trigger the builds before 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-13945) Copy artifacts from master -> slaves takes about 10x longer with openjdk
[ https://issues.jenkins-ci.org/browse/JENKINS-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163563#comment-163563 ] Leander Hasty commented on JENKINS-13945: - We're seeing something like this as well, on an upgrade from 1.455 to 1.466. It's much worse in our case: a build that is normally <20 minutes takes ~2 hours and may or may not complete successfully; usually it stalls on archiving artifacts, but we also see ludicrous delays downloading anything but the smallest files directly from the workspace. The console view also appears to be very behind reality. These slaves are all Ubuntu 10.04 LTS (they're actually running in VMWare on Windows XP 32-bit and 64-bit hosts). If we upgrade from the openjdk-6-jre package (6b20-1.9.13-0ubuntu version): << $ java -version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.13) (6b20-1.9.13-0ubuntu1~10.04.1) OpenJDK Client VM (build 19.0-b09, mixed mode, sharing) >> ... to a Java 7 package from Sun (via the "Repository" instructions at http://www.duinsoft.nl/packages.php?t=en ), the problem appears to go away. I've not yet tried other variants. > Copy artifacts from master -> slaves takes about 10x longer with openjdk > > > Key: JENKINS-13945 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13945 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Debian 6 >Reporter: sanga > > Version: 1.451 > We switched from sun java to openjdk and noticed that copying artifacts from > master to slave took way longer than it had previously (x10 or more). > Switching back to sun java fixed the problem. > Related to this, the node ping times, as seen at: > https://.../jenkins/computer/ were all up around 0.5s with openjdk and then > when switching to sun java dropped back down to where they should be (around > 20ms). > If this is a bug in openjdk that's not really Jenkins problem, but perhaps > there's something in Jenkins to be done. Or at least it'd be beneficial for > Jenkins to know about this I guess. -- 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-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[
https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163564#comment-163564
]
Luca Orlandi commented on JENKINS-13835:
Same issue here.
I've also downgraded to jenins 1.464 and subversion plugin 1.34 with NO SUCCESS
at all.
I cannot upgrade the server format as suggested in @stephenconnolly comment
because of a very large 1.6 repository
It's urgent for me to find a robust workaround (maybe something on apache
encoding?).
> upgrading Subversion Plugin to 1.40 totally ruined our CI server
>
>
> Key: JENKINS-13835
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
> Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39;
> Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16.
>Reporter: pancake
> Labels: plugin, subversion, windows
>
> Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
> resulted to {color:red}complete inability to perform a checkout. CI server is
> totally unusable now.{color}
> *Issue #1*
> After updating to Subversion Plugin to 1.40 (from 1.39) this exception
> started occurring _sometimes_ (various salves, various jobs):
> {quote}
> Checking out a fresh workspace because there's no workspace at
> C:\_JenkinsCI\workspace\XXX
> Cleaning local Directory .
> Checking out http://oursvnserver/svn/svnLatest/.../XXX
> A ...
> ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
> org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
> /svn/svnLatest/!svn/vcc/default failed
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
> at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
> at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
> at
> hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
> at
> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:287)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecuto
[JIRA] (JENKINS-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[
https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163564#comment-163564
]
Luca Orlandi edited comment on JENKINS-13835 at 6/6/12 5:51 PM:
Same issue here.
I've also downgraded to jenkins 1.464 and subversion plugin 1.34 with NO
SUCCESS at all.
I cannot upgrade the server format as suggested by @stephenconnolly comment
because of a very large 1.6 repository
It's urgent for me to find a robust workaround (maybe something on apache
encoding?).
was (Author: lrkwz):
Same issue here.
I've also downgraded to jenkins 1.464 and subversion plugin 1.34 with NO
SUCCESS at all.
I cannot upgrade the server format as suggested in @stephenconnolly comment
because of a very large 1.6 repository
It's urgent for me to find a robust workaround (maybe something on apache
encoding?).
> upgrading Subversion Plugin to 1.40 totally ruined our CI server
>
>
> Key: JENKINS-13835
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
> Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39;
> Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16.
>Reporter: pancake
> Labels: plugin, subversion, windows
>
> Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
> resulted to {color:red}complete inability to perform a checkout. CI server is
> totally unusable now.{color}
> *Issue #1*
> After updating to Subversion Plugin to 1.40 (from 1.39) this exception
> started occurring _sometimes_ (various salves, various jobs):
> {quote}
> Checking out a fresh workspace because there's no workspace at
> C:\_JenkinsCI\workspace\XXX
> Cleaning local Directory .
> Checking out http://oursvnserver/svn/svnLatest/.../XXX
> A ...
> ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
> org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
> /svn/svnLatest/!svn/vcc/default failed
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
> at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
> at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
> at
> hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
> at
> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Reque
[JIRA] (JENKINS-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[
https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163564#comment-163564
]
Luca Orlandi edited comment on JENKINS-13835 at 6/6/12 5:50 PM:
Same issue here.
I've also downgraded to jenkins 1.464 and subversion plugin 1.34 with NO
SUCCESS at all.
I cannot upgrade the server format as suggested in @stephenconnolly comment
because of a very large 1.6 repository
It's urgent for me to find a robust workaround (maybe something on apache
encoding?).
was (Author: lrkwz):
Same issue here.
I've also downgraded to jenins 1.464 and subversion plugin 1.34 with NO SUCCESS
at all.
I cannot upgrade the server format as suggested in @stephenconnolly comment
because of a very large 1.6 repository
It's urgent for me to find a robust workaround (maybe something on apache
encoding?).
> upgrading Subversion Plugin to 1.40 totally ruined our CI server
>
>
> Key: JENKINS-13835
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
> Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39;
> Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16.
>Reporter: pancake
> Labels: plugin, subversion, windows
>
> Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
> resulted to {color:red}complete inability to perform a checkout. CI server is
> totally unusable now.{color}
> *Issue #1*
> After updating to Subversion Plugin to 1.40 (from 1.39) this exception
> started occurring _sometimes_ (various salves, various jobs):
> {quote}
> Checking out a fresh workspace because there's no workspace at
> C:\_JenkinsCI\workspace\XXX
> Cleaning local Directory .
> Checking out http://oursvnserver/svn/svnLatest/.../XXX
> A ...
> ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
> org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
> /svn/svnLatest/!svn/vcc/default failed
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
> at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
> at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
> at
> hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
> at
> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Reques
[JIRA] (JENKINS-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[
https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Orlandi updated JENKINS-13835:
---
Labels: linux plugin subversion windows (was: plugin subversion windows)
> upgrading Subversion Plugin to 1.40 totally ruined our CI server
>
>
> Key: JENKINS-13835
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
> Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39;
> Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16.
>Reporter: pancake
> Labels: linux, plugin, subversion, windows
>
> Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
> resulted to {color:red}complete inability to perform a checkout. CI server is
> totally unusable now.{color}
> *Issue #1*
> After updating to Subversion Plugin to 1.40 (from 1.39) this exception
> started occurring _sometimes_ (various salves, various jobs):
> {quote}
> Checking out a fresh workspace because there's no workspace at
> C:\_JenkinsCI\workspace\XXX
> Cleaning local Directory .
> Checking out http://oursvnserver/svn/svnLatest/.../XXX
> A ...
> ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
> org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
> /svn/svnLatest/!svn/vcc/default failed
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
> at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
> at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
> at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
> at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
> at
> hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
> at
> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
> at
> hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
> at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:287)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: svn: E175002: REPORT /svn/svnLatest/!svn/vcc/default failed
> at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
> at
> org.tmatesoft.svn.core.SVNEr
[JIRA] (JENKINS-9829) The maven-deployment-linker plugin doesn't support the deployment from the post build task
[ https://issues.jenkins-ci.org/browse/JENKINS-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163565#comment-163565 ] Larry Shatzer, Jr. commented on JENKINS-9829: - Is this still an issue? > The maven-deployment-linker plugin doesn't support the deployment from the > post build task > -- > > Key: JENKINS-9829 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9829 > Project: Jenkins > Issue Type: Bug > Components: maven-deployment-linker >Reporter: Arnaud Héritier >Assignee: Larry Shatzer, Jr. > > If artifacts are not deployed within the build but after using the post build > task the maven-deployment-linker doesn't work. -- 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-14031) Anonymouse triggers 500 error
Christian Höltje created JENKINS-14031: -- Summary: Anonymouse triggers 500 error Key: JENKINS-14031 URL: https://issues.jenkins-ci.org/browse/JENKINS-14031 Project: Jenkins Issue Type: Bug Components: favorite Reporter: Christian Höltje Assignee: Larry Shatzer, Jr. I have the Role Strategy Plugin and Anonymous is configured with view permissions. But it causes a 500 error when visiting the default page for Jenkins (which I've configured to be Favorites)... Status Code: 500 Exception: org.apache.commons.jelly.JellyTagException: jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: Cannot invoke method isEmpty() on null object Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: Cannot invoke method isEmpty() on null object at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java: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.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 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 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.ja
[JIRA] (JENKINS-14031) Anonymouse triggers 500 error
[ https://issues.jenkins-ci.org/browse/JENKINS-14031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163566#comment-163566 ] Larry Shatzer, Jr. commented on JENKINS-14031: -- When you say "Favorites" did you mean the use of Favorite View (https://wiki.jenkins-ci.org/display/JENKINS/Favorite+View+Plugin) or Favorite (https://wiki.jenkins-ci.org/display/JENKINS/Favorite+Plugin)? > Anonymouse triggers 500 error > - > > Key: JENKINS-14031 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14031 > Project: Jenkins > Issue Type: Bug > Components: favorite >Reporter: Christian Höltje >Assignee: Larry Shatzer, Jr. > > I have the Role Strategy Plugin and Anonymous is configured with view > permissions. But it causes a 500 error when visiting the default page for > Jenkins (which I've configured to be Favorites)... > Status Code: 500 > Exception: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > Stacktrace: > javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > at > org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) > at > org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java: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.Stapler.invoke(Stapler.java:488) > at org.kohsuke.stapler.Stapler.service(Stapler.java:162) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > 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 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) > at > hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter
[JIRA] (JENKINS-14031) Anonymouse triggers 500 error
[ https://issues.jenkins-ci.org/browse/JENKINS-14031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163567#comment-163567 ] Christian Höltje commented on JENKINS-14031: Favorite: https://wiki.jenkins-ci.org/display/JENKINS/Favorite+Plugin > Anonymouse triggers 500 error > - > > Key: JENKINS-14031 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14031 > Project: Jenkins > Issue Type: Bug > Components: favorite >Reporter: Christian Höltje >Assignee: Larry Shatzer, Jr. > > I have the Role Strategy Plugin and Anonymous is configured with view > permissions. But it causes a 500 error when visiting the default page for > Jenkins (which I've configured to be Favorites)... > Status Code: 500 > Exception: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > Stacktrace: > javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > at > org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) > at > org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java: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.Stapler.invoke(Stapler.java:488) > at org.kohsuke.stapler.Stapler.service(Stapler.java:162) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > 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 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) > at > hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
[JIRA] (JENKINS-14031) Anonymouse triggers 500 error
[ https://issues.jenkins-ci.org/browse/JENKINS-14031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163568#comment-163568 ] Christian Höltje commented on JENKINS-14031: The default view is "Favorites" which is a view that uses the regular expression ".*" and applies the Favorites Filter. I have to admit that I'm *assuming* that this is due to the favorites because I don't see this 500 on any other views. But it's possible a column is doing this? My columns are: * Status * Weather * Name * Last Success * Last Failure * Last Duration * Favorite * Node Name > Anonymouse triggers 500 error > - > > Key: JENKINS-14031 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14031 > Project: Jenkins > Issue Type: Bug > Components: favorite >Reporter: Christian Höltje >Assignee: Larry Shatzer, Jr. > > I have the Role Strategy Plugin and Anonymous is configured with view > permissions. But it causes a 500 error when visiting the default page for > Jenkins (which I've configured to be Favorites)... > Status Code: 500 > Exception: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > Stacktrace: > javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > at > org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) > at > org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java: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.Stapler.invoke(Stapler.java:488) > at org.kohsuke.stapler.Stapler.service(Stapler.java:162) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > 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 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) > at > hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) > at > hudson.security.ChainedServletFilter$1.doFilter(Ch
[JIRA] (JENKINS-14032) No jobs showing up in view after upgrade to 1.466
K C created JENKINS-14032: - Summary: No jobs showing up in view after upgrade to 1.466 Key: JENKINS-14032 URL: https://issues.jenkins-ci.org/browse/JENKINS-14032 Project: Jenkins Issue Type: Bug Components: view-job-filters Affects Versions: current Environment: Production Reporter: K C Assignee: Jacob Robertson Upgraded from Hudson 1.346 to Jenkins 1.466. Biggest issue is existing jobs not showing up under existing views. These jobs and views were available and worked under Hudson 1.346. Jobs are still listed in teh config.xml files under the view and are also on the hard drive in the correct location. View does not show the job. How can I get the view to recognize the jobs in the config.xml. I even reverted back to the config.xml for hudson 1.346, still no jobs are shown. start/stop jenkins, reload configurations, etc still no jobs show up. What needs to be done to get this to work. Thanks -- 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-14033) "please wait while jenkins is getting ready to work...." displayed during build
K C created JENKINS-14033: - Summary: "please wait while jenkins is getting ready to work" displayed during build Key: JENKINS-14033 URL: https://issues.jenkins-ci.org/browse/JENKINS-14033 Project: Jenkins Issue Type: Bug Components: build-flow Affects Versions: current Environment: dev environment Reporter: K C Assignee: Nicolas De Loof *not sure if component is correct* When build is kicked off, sporadically "please wait while jenkins is getting ready to work" message displays several times, build continues to build and will eventually fail. Any suggestions or ideas as to what would cause this type of issue. -- 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-13420) Unable to serialize hudson.plugins.android_emulator.SdkInstaller
[
https://issues.jenkins-ci.org/browse/JENKINS-13420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163245#comment-163245
]
Hamilton Turner edited comment on JENKINS-13420 at 6/6/12 8:29 PM:
---
Should be fixed once
[https://github.com/jenkinsci/android-emulator-plugin/pull/11] is merged
was (Author: hamiltont):
Should be fixed once it's merged :
https://github.com/jenkinsci/android-emulator-plugin/pull/10
> Unable to serialize hudson.plugins.android_emulator.SdkInstaller
>
>
> Key: JENKINS-13420
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13420
> Project: Jenkins
> Issue Type: Bug
> Components: android-emulator
>Affects Versions: current
> Environment: Job running on a slave started via Java Web Start.
> Server running on the cloud, slave running inside our office.
>Reporter: Juraci P. Kroehling
>Assignee: Christopher Orr
>
> When starting a job which requires an Android SDK, we see the exception
> below. This happens if we use ANDROID_HOME pointing to an existing
> installation (in this case, the download of the SDK is not performed) as well
> as with automatic download of the needed "tools".
> {code}
> Started by user dashboard
> Building remotely on dashboard in workspace
> /tmp/jenkins/workspace/CI-emulatortest
> [android] No Android SDK found; let's install it automatically...
> Downloading and installing Android SDK from
> http://dl.google.com/android/android-sdk_r16-linux.tgz
> [android] Base SDK installed successfully
> [android] Going to install required Android SDK components...
> [android] Installing the 'platform-tool,tool' SDK component(s)...
> $ /tmp/jenkins/tools/android-sdk/tools/android update sdk -o -u -t
> platform-tool,tool
> Refresh Sources:
> Fetching https://dl-ssl.google.com/android/repository/addons_list-1.xml
> Validate XML
> Parse XML
> Fetched Add-ons List successfully
> Refresh Sources
> Fetching URL: https://dl-ssl.google.com/android/repository/repository-5.xml
> Validate XML: https://dl-ssl.google.com/android/repository/repository-5.xml
> Parse XML:https://dl-ssl.google.com/android/repository/repository-5.xml
> Fetching URL: https://dl-ssl.google.com/android/repository/addon.xml
> Validate XML: https://dl-ssl.google.com/android/repository/addon.xml
> Fetching URL: http://dl.htcdev.com/sdk/addon.xml
> Validate XML: http://dl.htcdev.com/sdk/addon.xml
> Parse XML:http://dl.htcdev.com/sdk/addon.xml
> Fetching URL: http://software.intel.com/sites/landingpage/android/addon.xml
> Validate XML: http://software.intel.com/sites/landingpage/android/addon.xml
> Parse XML:http://software.intel.com/sites/landingpage/android/addon.xml
> Fetching URL: http://www.echobykyocera.com/download/echo_repository.xml
> Validate XML: http://www.echobykyocera.com/download/echo_repository.xml
> Parse XML:http://www.echobykyocera.com/download/echo_repository.xml
> Fetching URL: http://developer.lgmobile.com/sdk/android/repository.xml
> Validate XML: http://developer.lgmobile.com/sdk/android/repository.xml
> Parse XML:http://developer.lgmobile.com/sdk/android/repository.xml
> Fetching URL: http://android-sdk-addons.motodevupdate.com/addons.xml
> Validate XML: http://android-sdk-addons.motodevupdate.com/addons.xml
> Parse XML:http://android-sdk-addons.motodevupdate.com/addons.xml
> Fetching URL:
> http://innovator.samsungmobile.com/android/repository/repository.xml
> Validate XML:
> http://innovator.samsungmobile.com/android/repository/repository.xml
> Parse XML:
> http://innovator.samsungmobile.com/android/repository/repository.xml
> Fetching URL: http://developer.sonyericsson.com/edk/android/repository.xml
> Validate XML: http://developer.sonyericsson.com/edk/android/repository.xml
> Parse XML:http://developer.sonyericsson.com/edk/android/repository.xml
> Refresh Sources:
> Fetching URL: https://dl-ssl.google.com/android/repository/addon.xml
> Validate XML: https://dl-ssl.google.com/android/repository/addon.xml
> Installing Archives:
> Preparing to install archives
> Downloading Android SDK Platform-tools, revision 11
> (22%, 1087 KiB/s, 7 seconds left)
> (41%, 1354 KiB/s, 4 seconds left)
> (59%, 1468 KiB/s, 2 seconds left)
> (77%, 1537 KiB/s, 1 seconds left)
> (94%, 1565 KiB/s, 0 seconds left)
> Installing Android SDK Platform-tools, revision 11
> Stopping ADB server failed (code -1).
> Unzipping Android SDK Platform-tools, revision 11 (4%)
> Unzipping Android SDK Platform-tools, revision 11 (5%)
> Unzipping Android SDK Platform-tools, revision 11 (6%)
> Unzipping Android SDK Platform-tools, revision 11 (9%)
> Unzipping Androi
[JIRA] (JENKINS-13959) StackOverflowException on Job Finish
[
https://issues.jenkins-ci.org/browse/JENKINS-13959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163569#comment-163569
]
Simon Schlachter commented on JENKINS-13959:
Michael, the above Stacktace is the full stacktrace I get from Jenkins
ConsoleLog - there is nothing else I can add from my side to this.
One more thing we found: If we *remove* the option "send email to individuals
who broke the build", the above exception disappears, so maybe it has something
to do with this part of the notification mechanism?
> StackOverflowException on Job Finish
>
>
> Key: JENKINS-13959
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13959
> Project: Jenkins
> Issue Type: Bug
> Components: cvs, notification
>Affects Versions: current
>Reporter: Simon Schlachter
> Attachments: example_fail_config.xml
>
>
> Since upgrading to jenkins 1.465 we get in some of our jobs the following
> stacktrace:
> {noformat}
> FATAL: null
> java.lang.StackOverflowError
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
> at
> java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
> at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
> at java.util.Calendar.updateTime(Calendar.java:2495)
> at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
> at java.util.Calendar.getMillisOf(Calendar.java:2512)
> at java.util.Calendar.equals(Calendar.java:1892)
> at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> ...
> {noformat}
> The Exception happens when the Job itself has finished and is about to report
> results to e-mail receivers.
> We were able to workaround the issue by removing the "send email
> notification" setting, storing the configuration and then re-add the
> notification setting, so
[JIRA] (JENKINS-13959) StackOverflowException on Job Finish
[
https://issues.jenkins-ci.org/browse/JENKINS-13959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Schlachter updated JENKINS-13959:
---
Attachment: plugins_jenkins.txt
Attaching file [^plugins_jenkins.txt] - as retrieved from the System Info Page
in Jenkins
> StackOverflowException on Job Finish
>
>
> Key: JENKINS-13959
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13959
> Project: Jenkins
> Issue Type: Bug
> Components: cvs, notification
>Affects Versions: current
>Reporter: Simon Schlachter
> Attachments: example_fail_config.xml, plugins_jenkins.txt
>
>
> Since upgrading to jenkins 1.465 we get in some of our jobs the following
> stacktrace:
> {noformat}
> FATAL: null
> java.lang.StackOverflowError
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
> at
> java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
> at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
> at java.util.Calendar.updateTime(Calendar.java:2495)
> at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
> at java.util.Calendar.getMillisOf(Calendar.java:2512)
> at java.util.Calendar.equals(Calendar.java:1892)
> at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> ...
> {noformat}
> The Exception happens when the Job itself has finished and is about to report
> results to e-mail receivers.
> We were able to workaround the issue by removing the "send email
> notification" setting, storing the configuration and then re-add the
> notification setting, so perhaps it has something to do with the notification
> part in jenkins itself.
> PS: The concerned Jobs do not all use CVS, some of them are git-only but get
> the exact same stacktrace as reported above.
--
This message is automatically generated by J
[JIRA] (JENKINS-13959) StackOverflowException on Job Finish
[
https://issues.jenkins-ci.org/browse/JENKINS-13959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163569#comment-163569
]
Simon Schlachter edited comment on JENKINS-13959 at 6/6/12 8:45 PM:
Michael, the above Stacktrace is the full stacktrace I get from Jenkins
ConsoleLog - there is nothing else I can add from my side to this. Or is there
some way how I can retrieve more Log than I find in the Job Log after the run?
One more thing we found: If we *remove* the option "send email to individuals
who broke the build", the above exception disappears, so maybe it has something
to do with this part of the notification mechanism?
was (Author: cappuccino):
Michael, the above Stacktace is the full stacktrace I get from Jenkins
ConsoleLog - there is nothing else I can add from my side to this.
One more thing we found: If we *remove* the option "send email to individuals
who broke the build", the above exception disappears, so maybe it has something
to do with this part of the notification mechanism?
> StackOverflowException on Job Finish
>
>
> Key: JENKINS-13959
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13959
> Project: Jenkins
> Issue Type: Bug
> Components: cvs, notification
>Affects Versions: current
>Reporter: Simon Schlachter
> Attachments: example_fail_config.xml, plugins_jenkins.txt
>
>
> Since upgrading to jenkins 1.465 we get in some of our jobs the following
> stacktrace:
> {noformat}
> FATAL: null
> java.lang.StackOverflowError
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266)
> at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243)
> at
> java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041)
> at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489)
> at java.util.Calendar.updateTime(Calendar.java:2495)
> at java.util.Calendar.getTimeInMillis(Calendar.java:1104)
> at java.util.Calendar.getMillisOf(Calendar.java:2512)
> at java.util.Calendar.equals(Calendar.java:1892)
> at java.util.GregorianCalendar.equals(GregorianCalendar.java:811)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608)
> at java.util.AbstractList.equals(AbstractList.java:524)
> at
> hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416)
> at hudson.scm.CVSChangeLo
[JIRA] (JENKINS-14034) Fail to download plugin
c mak created JENKINS-14034: --- Summary: Fail to download plugin Key: JENKINS-14034 URL: https://issues.jenkins-ci.org/browse/JENKINS-14034 Project: Jenkins Issue Type: Bug Components: plugin Environment: Windows server 2003; jenkin running as a window service. Update site setting: http://updates.jenkins-ci.org/update-center.json Reporter: c mak My version is "Jenkins ver. 1.466" When install a plugin, get the following error: Caused by: java.net.NoRouteToHostException: No route to host: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) -- 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-14031) Anonymouse triggers 500 error
[ https://issues.jenkins-ci.org/browse/JENKINS-14031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163571#comment-163571 ] Larry Shatzer, Jr. commented on JENKINS-14031: -- Hmmm... I can't see my code anywhere in the stacktrace, so I'm not sure were to look in my code. I'm also running role strategy plugin, and 1.467, and not having problems. > Anonymouse triggers 500 error > - > > Key: JENKINS-14031 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14031 > Project: Jenkins > Issue Type: Bug > Components: favorite >Reporter: Christian Höltje >Assignee: Larry Shatzer, Jr. > > I have the Role Strategy Plugin and Anonymous is configured with view > permissions. But it causes a 500 error when visiting the default page for > Jenkins (which I've configured to be Favorites)... > Status Code: 500 > Exception: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > Stacktrace: > javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: > jar:file:/opt/local/stow/apache-tomcat-7.0.6/share/apache-tomcat-7.0.6/webapps/automan/WEB-INF/lib/jenkins-core-1.467.jar!/hudson/model/View/index.jelly:44:43: > Cannot invoke method isEmpty() on null object > at > org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) > at > org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java: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.Stapler.invoke(Stapler.java:488) > at org.kohsuke.stapler.Stapler.service(Stapler.java:162) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > 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 hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) > at > hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegi
[JIRA] (JENKINS-13951) Custom workspace not resolved correctly after installing EnvInject
[
https://issues.jenkins-ci.org/browse/JENKINS-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163572#comment-163572
]
Gregory Boissinot commented on JENKINS-13951:
-
Are you sure?
I'm afraid I can't reproduce.
> Custom workspace not resolved correctly after installing EnvInject
> --
>
> Key: JENKINS-13951
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13951
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
>Affects Versions: current
> Environment: windows
>Reporter: Corey O'Brien
>Assignee: Gregory Boissinot
> Attachments: config.xml, slaveconfig.xml
>
>
> After installing EnvInject, existing jobs that have no EnvInject settings
> enabled are broken if they use a custom workspace. When running a job with a
> custom workspace on a slave, the custom workspace is ignored and %WORKSPACE%
> is set to the slave's root instead. Job configuration and the snippet from
> the jenkins config for the slave are attached.
> This is running with Jenkins 1.461 and EnvInject 1.54
> Here's the console output from the attached job:
> {noformat}
> [EnvInject] - Loading node environment variables.
> Building remotely on Master-Admin in workspace C:\envinjcustomws
> [envinjcustomws] $ cmd /c call
> C:\Users\jenkins\AppData\Local\Temp\hudson867880511665494930.bat
> C:\envinjcustomws>echo C:\Jenkins_AdminNode
> C:\Jenkins_AdminNode
> C:\envinjcustomws>exit 0
> Finished: SUCCESS
> {noformat}
> This may or may not be related to JENKINS-12027 which was resolved as fixed
> in 1.2 without confirmation.
--
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-13951) Custom workspace not resolved correctly after installing EnvInject
[
https://issues.jenkins-ci.org/browse/JENKINS-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JENKINS-13951 started by Gregory Boissinot.
> Custom workspace not resolved correctly after installing EnvInject
> --
>
> Key: JENKINS-13951
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13951
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
>Affects Versions: current
> Environment: windows
>Reporter: Corey O'Brien
>Assignee: Gregory Boissinot
> Attachments: config.xml, slaveconfig.xml
>
>
> After installing EnvInject, existing jobs that have no EnvInject settings
> enabled are broken if they use a custom workspace. When running a job with a
> custom workspace on a slave, the custom workspace is ignored and %WORKSPACE%
> is set to the slave's root instead. Job configuration and the snippet from
> the jenkins config for the slave are attached.
> This is running with Jenkins 1.461 and EnvInject 1.54
> Here's the console output from the attached job:
> {noformat}
> [EnvInject] - Loading node environment variables.
> Building remotely on Master-Admin in workspace C:\envinjcustomws
> [envinjcustomws] $ cmd /c call
> C:\Users\jenkins\AppData\Local\Temp\hudson867880511665494930.bat
> C:\envinjcustomws>echo C:\Jenkins_AdminNode
> C:\Jenkins_AdminNode
> C:\envinjcustomws>exit 0
> Finished: SUCCESS
> {noformat}
> This may or may not be related to JENKINS-12027 which was resolved as fixed
> in 1.2 without confirmation.
--
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-14020) Exception during workspace synchronize
[ https://issues.jenkins-ci.org/browse/JENKINS-14020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163573#comment-163573 ] Cletus D'Souza commented on JENKINS-14020: -- Is the file D:/tools/.jenkins/jobs/SPS4Pack/builds/2012-06-05_15-40-14/changelog.xml empty? > Exception during workspace synchronize > -- > > Key: JENKINS-14020 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14020 > Project: Jenkins > Issue Type: Bug > Components: integrity-plugin >Affects Versions: current > Environment: jenkins 1.465, PTC 1.13, WinXP 32bit SP3, no proxy, very > low bandwidth >Reporter: Cyril Jean >Assignee: Cletus D'Souza > > Have following exception during workspace resynchronize: > SEVERE: An error occurred while reading stream from > 'file:/D:/tools/.jenkins/jobs/SPS4Pack/builds/2012-06-05_15-40-14/changelog.xml', > see nested exceptions > com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: > Invalid byte 1 of 1-byte UTF-8 sequence. > at > com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown > Source) > at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown > Source) > at org.apache.commons.digester3.Digester.parse(Digester.java:1588) > at org.apache.commons.digester3.Digester.parse(Digester.java:1557) > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:65) > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:20) > at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:825) > at hudson.model.AbstractBuild.access$600(AbstractBuild.java:103) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:591) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) > at hudson.model.Run.run(Run.java:1434) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > hudson.util.IOException2: Failed to parse > D:\tools\.jenkins\jobs\SPS4Pack\builds\2012-06-05_15-40-14\changelog.xml > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:69) > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:20) > at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:825) > at hudson.model.AbstractBuild.access$600(AbstractBuild.java:103) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:591) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) > at hudson.model.Run.run(Run.java:1434) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > Caused by: > com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: > Invalid byte 1 of 1-byte UTF-8 sequence. > at > com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown > Source) > at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown > Source) > at > com.sun.org.apache.xerces.in
[JIRA] (JENKINS-10401) jenkins using 100% CPU if trying to archive unexisting artifact
[ https://issues.jenkins-ci.org/browse/JENKINS-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lloyd Chang reassigned JENKINS-10401: - Assignee: Lloyd Chang (was: aeschbacher) > jenkins using 100% CPU if trying to archive unexisting artifact > --- > > Key: JENKINS-10401 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10401 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Linux (debian squeeze 32bits) >Reporter: aeschbacher >Assignee: Lloyd Chang > > [Jenkins ver. 1.420] > If a jobs tries to archive an inexisting artifact, the jenkins process uses > 100% CPU forever, until we do a '/etc/init.d/jenkins stop' > The web interface can not anymore be used > The problem is not new in 1.420, but exists for a long time, already in > hudson (I did actually never see any linux version not having this problem). > A significant information is that we have a huge workspace (up to 45G - we > build distros with OpenEmbedded) shared between the jobs -- 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-8317) Matrix jobs with custom workspaces should be able to share the root with no axis-specific subtree
[
https://issues.jenkins-ci.org/browse/JENKINS-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163574#comment-163574
]
Joel Pearson commented on JENKINS-8317:
---
We also need this fixed. We're doing the cd ../../ fix at the moment, but it
kinda sucks because we have to disable scm integration and run the scm commands
inside a shell build step.
> Matrix jobs with custom workspaces should be able to share the root with no
> axis-specific subtree
> -
>
> Key: JENKINS-8317
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8317
> Project: Jenkins
> Issue Type: Improvement
> Components: core, matrix
>Affects Versions: current
>Reporter: mleinart
>Assignee: mleinart
>
> JENKINS-5077 created the ability to use custom workspaces in matrix jobs,
> however the implementation keeps the creation of a subtree specific to the
> axis and target (e.g. ${WORKSPACE}/axis1/a/axis2/b). This doesnt make sense
> some (most?) of the time as you're then not actually in the custom workspace
> you defined, but instead inside a subtree.
> We need an option to disable this subtree creation so that all runs of a
> matrix job can share the root of a custom workspace.
--
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-13909) Plugin update via manual upload fails on recent Jenkins version ?
[ https://issues.jenkins-ci.org/browse/JENKINS-13909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163576#comment-163576 ] dogfood commented on JENKINS-13909: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/yellow.png! [jenkins_main_trunk #1740|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1740/] [JENKINS-13909] don't keep legacy *.hpi when uploading a plugin (Revision de5938b3a65ea0f33bb0be077decce0b05683cd4) Result = UNSTABLE Nicolas De Loof : [de5938b3a65ea0f33bb0be077decce0b05683cd4|https://github.com/jenkinsci/jenkins/commit/de5938b3a65ea0f33bb0be077decce0b05683cd4] Files : * core/src/main/java/hudson/PluginManager.java > Plugin update via manual upload fails on recent Jenkins version ? > - > > Key: JENKINS-13909 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13909 > Project: Jenkins > Issue Type: Bug > Components: update-center > Environment: Jenkins 1.447.1, 1.465 >Reporter: Yama Tksh > > Plugin update via manual upload seems to have a problem relating to jpi/hpi > files. > Initially, our $JENKINS_HOME/plugins/ folder had the following contents: > * myplugin.hpi - old version > * myplugin/- old version > Then I uploaded a new version of myplugin.hpi file via web upload function on > the pluginManager/advanced page, > and restarted Jenkins. > 1). On Jenkins 1.424.6, the update succeeded. The plugins/ folder was updated > as follows: > * myplugin.hpi - new version (shown version name - OK) > * myplugin/- new version - OK > * (myplugin.bak file was not created) > 2). On Jenkins 1.447.1, the new version name was correctly shown in the > plugin list, > but the update itself failed: > * myplugin.jpi - new version (shown version name - OK) > * myplugin.hpi - old version > * myplugin/- old version - NG > 3). On Jenkins 1.465, the update itself succeeded, but the old version name > was shown: > * myplugin.jpi - new version > * myplugin.hpi - old version (shown version name - NG) > * myplugin/- new version - OK > In the cases of 2) and 3), > when I removed myplugin.hpi and restarted Jenkins, > then both of the update and shown version name became O.K. -- 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-13378) XML API Logs Too Much Information When Invalid Char is Present
[ https://issues.jenkins-ci.org/browse/JENKINS-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163575#comment-163575 ] dogfood commented on JENKINS-13378: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/yellow.png! [jenkins_main_trunk #1740|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1740/] [FIXED JENKINS-13378] Remove XML string writer from IOException2 when XPath error occurs. (Revision 668a0cc4dc786dc1b6a726b17db74e9974afa82a) [JENKINS-13378] Add FINER logging of XML when XPath handling fails. (Revision e1a1d3f098d938fb9c4690cd283653a91a496ae6) [JENKINS-13378] Update changelog.html with fix. (Revision 752a7c7b8bd357f2962c0b361eef465b1fd1c83f) Result = UNSTABLE thomas.vandoren : [668a0cc4dc786dc1b6a726b17db74e9974afa82a|https://github.com/jenkinsci/jenkins/commit/668a0cc4dc786dc1b6a726b17db74e9974afa82a] Files : * core/src/main/java/hudson/model/Api.java thomas.vandoren : [e1a1d3f098d938fb9c4690cd283653a91a496ae6|https://github.com/jenkinsci/jenkins/commit/e1a1d3f098d938fb9c4690cd283653a91a496ae6] Files : * core/src/main/java/hudson/model/Api.java thomas.vandoren : [752a7c7b8bd357f2962c0b361eef465b1fd1c83f|https://github.com/jenkinsci/jenkins/commit/752a7c7b8bd357f2962c0b361eef465b1fd1c83f] Files : * changelog.html > XML API Logs Too Much Information When Invalid Char is Present > -- > > Key: JENKINS-13378 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13378 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Thomas Van Doren >Assignee: Thomas Van Doren > Labels: api, exception, jenkins > > When an XPath error occurs when calling the /api/xml API, the entire xml > string writer object is included as part of the exception. While this could > be useful in some circumstances, it poses a problem when there is a > significant amount of xml (i.e. tens or hundreds of megabytes). > Recently I saw this in my jenkins installation. One of the chrome extensions > calls "/api/xml?depth=2&xpath=/*/job/lastBuild&wrapper=hudson" to get > information every minute or two. I was seeing 150MB of log data every time > that call was made because there was a stack trace followed by: > Caused by: hudson.util.IOException2: Failed to do XPath/wrapper handling. XML > is as > follows:0... > [150MB of xml] > at hudson.model.Api.doXml(Api.java:142) > ... 63 more > Caused by: org.dom4j.DocumentException: Error on line 2170 of document : An > invalid XML character (Unicode: 0x10) was found in the element content of the > document. Nested exception: An invalid XML character (Unicode: 0x10) was > found in the element content of the document. > at org.dom4j.io.SAXReader.read(SAXReader.java:482) > at org.dom4j.io.SAXReader.read(SAXReader.java:365) > at hudson.model.Api.doXml(Api.java:100) > ... 63 more > Caused by: org.xml.sax.SAXParseException: An invalid XML character (Unicode: > 0x10) was found in the element content of the document. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) > at > com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2894) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > at org.dom4j.io.SAXReader.read(SAXReader.java:465) > ... 65 more > It didn't take very long for the log file to consume all of the available > disk space on the serv
[JIRA] (JENKINS-8317) Matrix jobs with custom workspaces should be able to share the root with no axis-specific subtree
[
https://issues.jenkins-ci.org/browse/JENKINS-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Pearson resolved JENKINS-8317.
---
Resolution: Fixed
It turns out it was fixed in 1.467 3 days ago:
Matrix custom workspace support is improved to allow configuration builds to
share workspace
You just set the "Directory for sub-builds" to "."
> Matrix jobs with custom workspaces should be able to share the root with no
> axis-specific subtree
> -
>
> Key: JENKINS-8317
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8317
> Project: Jenkins
> Issue Type: Improvement
> Components: core, matrix
>Affects Versions: current
>Reporter: mleinart
>Assignee: mleinart
>
> JENKINS-5077 created the ability to use custom workspaces in matrix jobs,
> however the implementation keeps the creation of a subtree specific to the
> axis and target (e.g. ${WORKSPACE}/axis1/a/axis2/b). This doesnt make sense
> some (most?) of the time as you're then not actually in the custom workspace
> you defined, but instead inside a subtree.
> We need an option to disable this subtree creation so that all runs of a
> matrix job can share the root of a custom workspace.
--
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-14035) Responsive design
OHTAKE Tomohiro created JENKINS-14035:
-
Summary: Responsive design
Key: JENKINS-14035
URL: https://issues.jenkins-ci.org/browse/JENKINS-14035
Project: Jenkins
Issue Type: New Feature
Components: ui-changes
Reporter: OHTAKE Tomohiro
Assignee: OHTAKE Tomohiro
Make Web UI responsive for better experience with smartphones.
{noformat:title=Desktops (current design)}
+---+
|Top Bar|
+---+
|Breadcrumbs|
+-+-+
|side-| main-panel |
|panel| |
| | |
+-+-+
|Footer |
+---+
{noformat}
{noformat:title=Smartphones}
+---+
|Top bar|
+---+
|Breadcrumbs|
+---+
|side-panel |
|(togglable)|
+---+
|main-panel |
| |
| |
+---+
|Footer |
+---+
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14003) Starteam plugin takes a very long time for code check out
[ https://issues.jenkins-ci.org/browse/JENKINS-14003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163578#comment-163578 ] K Ningthouj commented on JENKINS-14003: --- Yes, projects with huge files are more slower. Our project is quite huge and consists of around 3000 files. ST set up is a dedicated one and Jenkins is on a separate machine from ST. Started by user anonymous No emails were triggered. [workspace] $ cmd /c call C:\Windows\TEMP\hudson7170137422339611690.bat C:\Program Files\Jenkins\jobs\BUILD1\workspace>stcmd co -p "test:testpwd@*:/sourceproject/viewname" -is -F NCO -rp "C:\Jenkins\Codebase\Project" "*" StarTeam 11.0 Command Line Interface, Build 11.0.0.54 Copyright (c) 2003-2009 Borland Software Corporation. All rights reserved. Using ini file: C:\ProgramData\Borland\StarTeam\ConnectionManager.ini Folder: Code (working dir: C:\Jenkins\Codebase\Project) Folder: prototype (working dir: C:\Jenkins\Codebase\Project\prototype) readme.txt: checked out Using command line, it takes around 10 minutes to do a clean checkout (after removing the local directory). Subsequent checkouts are pretty fast < 1 min. > Starteam plugin takes a very long time for code check out > - > > Key: JENKINS-14003 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14003 > Project: Jenkins > Issue Type: Improvement > Components: starteam >Reporter: K Ningthouj >Assignee: jan_ruzicka > > We are using Starteam plugin with Jenkins for our project. When we perform > check-outs, it takes a very long time unlike when we run the starteam command > line using stcmd which is pretty fast. Is there any possibility in the > current plug-in that provides a way that we can pass a parameter just like > the starteam command line to speed up the checkout process? -- 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
