[JIRA] (JENKINS-13087) Clone to directory named for repository
[ https://issues.jenkins-ci.org/browse/JENKINS-13087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] OHTAKE Tomohiro resolved JENKINS-13087. --- Resolution: Duplicate > Clone to directory named for repository > --- > > Key: JENKINS-13087 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13087 > Project: Jenkins > Issue Type: New Feature > Components: git >Affects Versions: current >Reporter: Tom Haggie >Assignee: Nicolas De Loof >Priority: Minor > Labels: git, jenkins > > In a Jenkins Job you can select to use git to clone / pull from multiple > repositories but it always pulls straight to the working directory so if you > have multiple they end up overwriting each other. > What I'd like is a checkbox to say clone to a directory (under the workspace) > named for the git repository. > So (when checked) if I had the command as: > https://github.com/jenkinsci/jenkins.git > it would checkout to .../workspace/job_name/jenkins -- 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-13082) Breadcrumb popup menu gives javascript error on Internet Explorer 8
[ https://issues.jenkins-ci.org/browse/JENKINS-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160272#comment-160272 ] OHTAKE Tomohiro commented on JENKINS-13082: --- I have raised a pull request. https://github.com/jenkinsci/jenkins/pull/407 > Breadcrumb popup menu gives javascript error on Internet Explorer 8 > --- > > Key: JENKINS-13082 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13082 > Project: Jenkins > Issue Type: Bug > Components: www >Affects Versions: current > Environment: jenkins 1.455 running on linux, client is internet > explorer 8 running on windows xp > also happens on ci.jenkins-ci.org (1.456 rc) with client internet explorer 8 >Reporter: Alex Lehmann >Assignee: OHTAKE Tomohiro >Priority: Blocker > Labels: gui, windows > > when moving the mouse over the breadcrumb tabs, a javascript error shows in > Internet Explorer 8 > User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; > .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; > .NET4.0E) > Timestamp: Wed, 14 Mar 2012 22:55:57 UTC > Message: 'left' is null or not an object > Line: 8 > Char: 5672 > Code: 0 > URI: http://ci.jenkins-ci.org/static/6c4cb891/scripts/yui/dom/dom-min.js -- 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-13086) Clone to directory named for repository
Tom Haggie created JENKINS-13086: Summary: Clone to directory named for repository Key: JENKINS-13086 URL: https://issues.jenkins-ci.org/browse/JENKINS-13086 Project: Jenkins Issue Type: New Feature Components: git Affects Versions: current Reporter: Tom Haggie Assignee: Nicolas De Loof Priority: Minor In a Jenkins Job you can select to use git to clone / pull from multiple repositories but it always pulls straight to the working directory so if you have multiple they end up overwriting each other. What I'd like is a checkbox to say clone to a directory (under the workspace) named for the git repository. So (when checked) if I had the command as: https://github.com/jenkinsci/jenkins.git it would checkout to .../workspace/job_name/jenkins -- 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-13087) Clone to directory named for repository
Tom Haggie created JENKINS-13087: Summary: Clone to directory named for repository Key: JENKINS-13087 URL: https://issues.jenkins-ci.org/browse/JENKINS-13087 Project: Jenkins Issue Type: New Feature Components: git Affects Versions: current Reporter: Tom Haggie Assignee: Nicolas De Loof Priority: Minor In a Jenkins Job you can select to use git to clone / pull from multiple repositories but it always pulls straight to the working directory so if you have multiple they end up overwriting each other. What I'd like is a checkbox to say clone to a directory (under the workspace) named for the git repository. So (when checked) if I had the command as: https://github.com/jenkinsci/jenkins.git it would checkout to .../workspace/job_name/jenkins -- 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-13082) Breadcrumb popup menu gives javascript error on Internet Explorer 8
[ https://issues.jenkins-ci.org/browse/JENKINS-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] OHTAKE Tomohiro reassigned JENKINS-13082: - Assignee: OHTAKE Tomohiro > Breadcrumb popup menu gives javascript error on Internet Explorer 8 > --- > > Key: JENKINS-13082 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13082 > Project: Jenkins > Issue Type: Bug > Components: www >Affects Versions: current > Environment: jenkins 1.455 running on linux, client is internet > explorer 8 running on windows xp > also happens on ci.jenkins-ci.org (1.456 rc) with client internet explorer 8 >Reporter: Alex Lehmann >Assignee: OHTAKE Tomohiro >Priority: Blocker > Labels: gui, windows > > when moving the mouse over the breadcrumb tabs, a javascript error shows in > Internet Explorer 8 > User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; > .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; > .NET4.0E) > Timestamp: Wed, 14 Mar 2012 22:55:57 UTC > Message: 'left' is null or not an object > Line: 8 > Char: 5672 > Code: 0 > URI: http://ci.jenkins-ci.org/static/6c4cb891/scripts/yui/dom/dom-min.js -- 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-12583) update for cvs plugin to 2.0 doesn't work
[
https://issues.jenkins-ci.org/browse/JENKINS-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160271#comment-160271
]
Vince McIntyre edited comment on JENKINS-12583 at 3/15/12 5:04 AM:
---
A comment. In 1.455 (installed via the .deb package) the .war contains
references to .hpi files, but the pinning stuff only works properly with .jpi
files.
{code}
% unzip -l /usr/share/jenkins/jenkins.war|grep hpi|awk '{print $NF}'
WEB-INF/plugins/ssh-slaves.hpi
WEB-INF/plugins/javadoc.hpi
WEB-INF/plugins/cvs.hpi
WEB-INF/plugins/translation.hpi
WEB-INF/plugins/ant.hpi
WEB-INF/plugins/maven-plugin.hpi
WEB-INF/plugins/subversion.hpi
{code}
{code}
% find /var/lib/jenkins/ -name "*.hpi*"
%
% find /var/lib/jenkins/ -name "*.pinn*"
/var/lib/jenkins/plugins/cvs.jpi.pinned
/var/lib/jenkins/plugins/subversion.jpi.pinned
%
{code}
was (Author: xipmix):
A comment. In 1.455 the .war contains references to .hpi files, but the
pinning stuff only works properly with .jpi files.
{code}
% unzip -l /usr/share/jenkins/jenkins.war|grep hpi|awk '{print $NF}'
WEB-INF/plugins/ssh-slaves.hpi
WEB-INF/plugins/javadoc.hpi
WEB-INF/plugins/cvs.hpi
WEB-INF/plugins/translation.hpi
WEB-INF/plugins/ant.hpi
WEB-INF/plugins/maven-plugin.hpi
WEB-INF/plugins/subversion.hpi
{code}
{code}
% find /var/lib/jenkins/ -name "*.hpi*"
%
% find /var/lib/jenkins/ -name "*.pinn*"
/var/lib/jenkins/plugins/cvs.jpi.pinned
/var/lib/jenkins/plugins/subversion.jpi.pinned
%
{code}
> update for cvs plugin to 2.0 doesn't work
> -
>
> Key: JENKINS-12583
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12583
> Project: Jenkins
> Issue Type: Bug
> Components: cvs
>Affects Versions: current
> Environment: jenkins 1.449, cvs plugin 1.6
>Reporter: Alex Lehmann
>Assignee: Alex Lehmann
> Fix For: current
>
>
> I tried to update to the cvs plugin 2.0 today but this doesn't work, I assume
> there is a name problem due to the extension *.jpi on the new plugin.
> Before update, the file is called cvs.hpi, the update process creates a new
> file cvs.jpi that is ignored with the following message:
> Jan 30, 2012 5:04:26 PM hudson.PluginManager$1$3$1 isDuplicate
> INFO: Ignoring /home/lehmann/.jenkins/plugins/cvs.jpi because
> /home/lehmann/.jenkins/plugins/cvs.hpi is already loaded
> I assume it may work if it were the other way around.
> The version displayed by the plugin page remains 1.6 but there are a few
> exceptions in the log about missing classes like this
> java.lang.NoClassDefFoundError: org/netbeans/lib/cvsclient/admin/AdminHandler
> these classes are included in the cvs.jpi zip but that is not used.
> I was able to fix the update manually by copying cvs.jpi to cvs.hpi, which
> resulted in a pinned plugin 2.0, but the automatic process has to be fixed
> somehow.
--
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-12583) update for cvs plugin to 2.0 doesn't work
[
https://issues.jenkins-ci.org/browse/JENKINS-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160271#comment-160271
]
Vince McIntyre commented on JENKINS-12583:
--
A comment. In 1.455 the .war contains references to .hpi files, but the pinning
stuff only works properly with .jpi files.
{code}
% unzip -l /usr/share/jenkins/jenkins.war|grep hpi|awk '{print $NF}'
WEB-INF/plugins/ssh-slaves.hpi
WEB-INF/plugins/javadoc.hpi
WEB-INF/plugins/cvs.hpi
WEB-INF/plugins/translation.hpi
WEB-INF/plugins/ant.hpi
WEB-INF/plugins/maven-plugin.hpi
WEB-INF/plugins/subversion.hpi
{code}
{code}
% find /var/lib/jenkins/ -name "*.hpi*"
%
% find /var/lib/jenkins/ -name "*.pinn*"
/var/lib/jenkins/plugins/cvs.jpi.pinned
/var/lib/jenkins/plugins/subversion.jpi.pinned
%
{code}
> update for cvs plugin to 2.0 doesn't work
> -
>
> Key: JENKINS-12583
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12583
> Project: Jenkins
> Issue Type: Bug
> Components: cvs
>Affects Versions: current
> Environment: jenkins 1.449, cvs plugin 1.6
>Reporter: Alex Lehmann
>Assignee: Alex Lehmann
> Fix For: current
>
>
> I tried to update to the cvs plugin 2.0 today but this doesn't work, I assume
> there is a name problem due to the extension *.jpi on the new plugin.
> Before update, the file is called cvs.hpi, the update process creates a new
> file cvs.jpi that is ignored with the following message:
> Jan 30, 2012 5:04:26 PM hudson.PluginManager$1$3$1 isDuplicate
> INFO: Ignoring /home/lehmann/.jenkins/plugins/cvs.jpi because
> /home/lehmann/.jenkins/plugins/cvs.hpi is already loaded
> I assume it may work if it were the other way around.
> The version displayed by the plugin page remains 1.6 but there are a few
> exceptions in the log about missing classes like this
> java.lang.NoClassDefFoundError: org/netbeans/lib/cvsclient/admin/AdminHandler
> these classes are included in the cvs.jpi zip but that is not used.
> I was able to fix the update manually by copying cvs.jpi to cvs.hpi, which
> resulted in a pinned plugin 2.0, but the automatic process has to be fixed
> somehow.
--
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-12583) update for cvs plugin to 2.0 doesn't work
[ https://issues.jenkins-ci.org/browse/JENKINS-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160270#comment-160270 ] Vince McIntyre commented on JENKINS-12583: -- Still seeing this on a fresh install of 1.454, and after upgrade to 1.455. The workaround of touching the .hpi for bundled plugins still works. > update for cvs plugin to 2.0 doesn't work > - > > Key: JENKINS-12583 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12583 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: jenkins 1.449, cvs plugin 1.6 >Reporter: Alex Lehmann >Assignee: Alex Lehmann > Fix For: current > > > I tried to update to the cvs plugin 2.0 today but this doesn't work, I assume > there is a name problem due to the extension *.jpi on the new plugin. > Before update, the file is called cvs.hpi, the update process creates a new > file cvs.jpi that is ignored with the following message: > Jan 30, 2012 5:04:26 PM hudson.PluginManager$1$3$1 isDuplicate > INFO: Ignoring /home/lehmann/.jenkins/plugins/cvs.jpi because > /home/lehmann/.jenkins/plugins/cvs.hpi is already loaded > I assume it may work if it were the other way around. > The version displayed by the plugin page remains 1.6 but there are a few > exceptions in the log about missing classes like this > java.lang.NoClassDefFoundError: org/netbeans/lib/cvsclient/admin/AdminHandler > these classes are included in the cvs.jpi zip but that is not used. > I was able to fix the update manually by copying cvs.jpi to cvs.hpi, which > resulted in a pinned plugin 2.0, but the automatic process has to be fixed > somehow. -- 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-13085) Environment Variable Injection doesn't work when project
Josh Davidson created JENKINS-13085: --- Summary: Environment Variable Injection doesn't work when project Key: JENKINS-13085 URL: https://issues.jenkins-ci.org/browse/JENKINS-13085 Project: Jenkins Issue Type: Bug Components: envinject Affects Versions: current Reporter: Josh Davidson Assignee: gbois When a slave node is configured to append/prepend to a variable (Node Properties->Environment Variables) that is used by EnvInject within a job, the injection fails. If the slave node simply sets the variable (i.e. doesn't reference the same variable in the act of setting) it works fine. Consider the following job, which has a single build step: echo $PATH In Build Environment->Inject, there is a single line in the properties content box: PATH=/opt/bin:$PATH That's the job. Now, the slave node, also sets the PATH variable. Let's first look at a working example, where the slave node sets PATH to: /data/goesrsw/goesr/bin Here is the output: [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content PATH=/opt/bin:$PATH [EnvInject] - Variables injected successfully. [aaa] $ bash -xe /tmp/hudson5838824311735104563.sh + echo /opt/bin:/data/goesrsw/goesr/bin /opt/bin:/data/goesrsw/goesr/bin Notifying upstream projects of job completion Finished: SUCCESS Ok, so to demonstrate the problem, change the PATH in the slave node to: /data/goesrsw/goesr/bin:$PATH Now, here's the output: [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content PATH=/opt/bin:$PATH [EnvInject] - Variables injected successfully. [EnvInject] - Unset unresolved 'PATH' variable. [aaa] $ bash -xe /tmp/hudson3276485997068093627.sh + echo /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind Notifying upstream projects of job completion Finished: SUCCESS As you can see, the injection didn't work. /opt/bin is nowhere to be found. -- 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-11409) Gerrit-trigger should support waiting for downstream jobs of triggered builds
[ https://issues.jenkins-ci.org/browse/JENKINS-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160269#comment-160269 ] Roland Schulz commented on JENKINS-11409: - A partial solution would be to combine the messages of several jobs each triggered by the plugin, before posting them to Gerrit. This would allow one to tell the plugin to trigger several jobs without getting as many comments (and emails) in Gerrit. This would (probably) only help for jobs which are independent (unless it is somehow possible to wait on the dependent jobs). > Gerrit-trigger should support waiting for downstream jobs of triggered builds > - > > Key: JENKINS-11409 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11409 > Project: Jenkins > Issue Type: Improvement > Components: gerrit-trigger >Reporter: Jørgen Tjernø >Assignee: rsandell > > When using gerrit-trigger to trigger a build from Gerrit, gerrit-trigger > should have support for waiting for downstream jobs to complete (and take > those into considerations). > The use case is to have a build job followed by a test job (if the build > completes), but currently gerrit-trigger will report success as soon as the > build job finishes. > The work-around is to create a wrapper job that uses parameterized trigger to > start a "blocking" build of the build job, followed by a "blocking" build of > the test job. The downside of this is that the wrapper occupies a slot on an > executor, even though it just blocks, and that the output in gerrit doesn't > clearly indicate if building or testing failed. -- 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-13083) Identify downstream matrix project with fingerprint
[ https://issues.jenkins-ci.org/browse/JENKINS-13083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160268#comment-160268 ] Roland Schulz commented on JENKINS-13083: - A possible partial solution to solve the problem in the core, is to identify downstream builds without fingerprint. I filed a separate issue for that as 13084. > Identify downstream matrix project with fingerprint > --- > > Key: JENKINS-13083 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13083 > Project: Jenkins > Issue Type: Improvement > Components: matrix >Reporter: Roland Schulz > > If a standard free-sytle downstream job is fingerprinting a file it is > correctly identified as downstream build. But for a downstream matrix job > this does not work. This is even though the fingerprinting works correctly as > seen by fingerprint details. The fingerprint shows each of the configurations > of the matrix job as a user of the file. > This issue has been described before at > http://jenkins.361315.n4.nabble.com/Question-about-Matrix-project-amp-fingerprints-amp-Join-plugin-td3857309.html -- 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-13084) Identify project triggered by other project as downstream project without fingerprinting
Roland Schulz created JENKINS-13084: --- Summary: Identify project triggered by other project as downstream project without fingerprinting Key: JENKINS-13084 URL: https://issues.jenkins-ci.org/browse/JENKINS-13084 Project: Jenkins Issue Type: Improvement Components: core Reporter: Roland Schulz Currently downstream project are only identified through fingerprinting. It would be great that projects which are directly triggered by another project would be shown as a downstream job even without any fingerprinting. The information is available because the downstream job already shows the link to the upstream project. Thus I would imagine it should be possible to show the link also in the other direction without fingerprinting. The reasons I suggest to show the downstream project also without fingerprint are: 1) Requiring fingerprinting makes it more difficult if the downstream project doesn't need any file of the upstream project. E.g. because of issue 11409 it is required to have a wrapper job which triggers a couple of other jobs. The wrapper job does not produce any files which can be fingerprinted. As a workaround, one can create a file (e.g. with the BUILD_TAG as content) to have a correct fingerprint, but that workaround shouldn't be necessary. 2) Currently matrix jobs aren't identified as downstream projects. It might be possible to address this using fingerprinting and I filed it as a separate issue: 13083. But using fingerprinting it is not clear whether the job or each configuration should be marked as downstream. Thus it might be easier to address the matrix issue by the suggestion described here. -- 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-11783) SAXParser-related IllegalAccessError on svn update
[
https://issues.jenkins-ci.org/browse/JENKINS-11783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160267#comment-160267
]
Ben Ernst commented on JENKINS-11783:
-
I have what seems to be the same behaviour here, Jenkins 1.455. I also had the
Maven plugin disabled. Thanks *Conny*, the same workaround worked for me,
*enabling the Maven plugin* appears to have fixed the issue.
> SAXParser-related IllegalAccessError on svn update
> --
>
> Key: JENKINS-11783
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11783
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
>Affects Versions: current
> Environment: Jenkins ver. 1.439
> Jenkins Subversion Plug-in1.34
>Reporter: pancake
>Assignee: Kohsuke Kawaguchi
>Priority: Critical
>
> This started to occur after a recent update to Jenkins ver. 1.439 + Jenkins
> Subversion Plug-in 1.34.
> It only happens on *some slaves, not others* \- while they are (at least at
> 1st glance) are totally identical.
> I did these steps, and the problem was fixed for *some* slaves:
> - deleted job workspaces;
> - deleted %APPDATA%\Subversion;
> - cleared %USERPROFILE%\Local Settings\Temp;
> - cleared %TMP%, %TEMP% (we override these env vars in slave nodes'
> configuration) Jenkins service uses;
> - removed %JENKINS_HOME%\*.jar.
> {noformat}
> 15:02:14 Checking out a fresh workspace because there's no workspace at
> C:\_JenkinsCI\workspace\for_maintenance
> 15:02:14 Cleaning local Directory .
> 15:02:14 Checking out http://server/rep
> 15:02:14 hudson.util.IOException2: remote file operation failed:
> C:\_JenkinsCI\workspace\for_maintenance at
> hudson.remoting.Channel@a18951:hudson32
> 15:02:14 at hudson.FilePath.act(FilePath.java:781)
> 15:02:14 at hudson.FilePath.act(FilePath.java:767)
> 15:02:14 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735)
> 15:02:14 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677)
> 15:02:14 at
> hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> 15:02:14 at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:568)
> 15:02:14 at
> hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:456)
> 15:02:14 at hudson.model.Run.run(Run.java:1404)
> 15:02:14 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> 15:02:14 at
> hudson.model.ResourceController.execute(ResourceController.java:88)
> 15:02:14 at hudson.model.Executor.run(Executor.java:230)
> 15:02:14 Caused by: java.io.IOException: Remote call on hudson32 failed
> 15:02:14 at hudson.remoting.Channel.call(Channel.java:690)
> 15:02:14 at hudson.FilePath.act(FilePath.java:774)
> 15:02:14 ... 10 more
> 15:02:14 Caused by: java.lang.IllegalAccessError: tried to access method
> org.apache.xerces.jaxp.SAXParserImpl.(Lorg/apache/xerces/jaxp/SAXParserFactoryImpl;Ljava/util/Hashtable;Z)V
> from class org.apache.xerces.jaxp.SAXParserFactoryImpl
> 15:02:14 at
> org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:745)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:719)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:216)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:364)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doPropfind(DAVConnection.java:126)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getProperties(DAVUtil.java:73)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getResourceProperties(DAVUtil.java:79)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getStartingProperties(DAVUtil.java:103)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:125)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineProperties(DAVUtil.java:226)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineInfo(DAVUtil.java:184)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:182)
> 15:02:14
[JIRA] (JENKINS-13083) Identify downstream matrix project with fingerprint
Roland Schulz created JENKINS-13083: --- Summary: Identify downstream matrix project with fingerprint Key: JENKINS-13083 URL: https://issues.jenkins-ci.org/browse/JENKINS-13083 Project: Jenkins Issue Type: Improvement Components: matrix Reporter: Roland Schulz If a standard free-sytle downstream job is fingerprinting a file it is correctly identified as downstream build. But for a downstream matrix job this does not work. This is even though the fingerprinting works correctly as seen by fingerprint details. The fingerprint shows each of the configurations of the matrix job as a user of the file. This issue has been described before at http://jenkins.361315.n4.nabble.com/Question-about-Matrix-project-amp-fingerprints-amp-Join-plugin-td3857309.html -- 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-12427) BuildResultTrigger Plug-in not triggering job
[ https://issues.jenkins-ci.org/browse/JENKINS-12427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S P resolved JENKINS-12427. --- Resolution: Cannot Reproduce Yes, those rules you mention are fine for what I'm trying to do. I can't figure out why it isn't working for us and I don't know where else to look. I'll close the issue and try to work on it again another day. Thanks for your time > BuildResultTrigger Plug-in not triggering job > -- > > Key: JENKINS-12427 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12427 > Project: Jenkins > Issue Type: Bug > Components: buildresult-trigger, buildresulttrigger >Affects Versions: current > Environment: Linux, 2.6.26-amd64 > debian_version 5.0.6 > Jenkins BuildResultTrigger Plug-in 0.4 > Jenkins ver. 1.440 >Reporter: S P >Assignee: gbois > Attachments: TEST-Trigger.config.xml, TEST-TRY.config-2.xml, > TEST-TRY.config.xml > > > Jenkins with the buildResultTrigger plugin is unable to trigger a job > Two jobs are setup, > 1. TEST-TRIGGER is a basic job that always passes > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:47:31 | 17/01/2012 10:47:31 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:47:31 | INFO: TEST-Trigger #7 main build > action completed: SUCCESS > > 2. TEST-TRY is a basic job configured to Monitor build results of > TEST-Trigger. This job is able to run with success when trigger manually > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:48:51 | 17/01/2012 10:48:51 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:48:51 | INFO: TEST-TRY #2 main build action > completed: SUCCESS > However, a success result from TEST-TRIGGER does not fire the TEST-TRY job. > Both jobs configurations are attached -- 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-12978) NullPointerException saving jenkins configuration
[ https://issues.jenkins-ci.org/browse/JENKINS-12978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160265#comment-160265 ] Joel Beaudoin commented on JENKINS-12978: - We are simply using a dummy cron comment in the problematic schedule field (# ...) to work-around this issue; however, I see that even though there is a fix checked in, the problem is still present in the latest Jenkins (1.455). I'm curious about when this will be integrated into a release? > NullPointerException saving jenkins configuration > - > > Key: JENKINS-12978 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12978 > Project: Jenkins > Issue Type: Bug > Components: maven-repo-cleaner >Reporter: Nicolas De Loof > > how to reproduce : > edit jenkins configuration, leave maven-repo-cleaner cron expression empty > save > -> NullPointerException -- 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-12427) BuildResultTrigger Plug-in not triggering job
[ https://issues.jenkins-ci.org/browse/JENKINS-12427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160264#comment-160264 ] gbois commented on JENKINS-12427: - Does it suit you? > BuildResultTrigger Plug-in not triggering job > -- > > Key: JENKINS-12427 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12427 > Project: Jenkins > Issue Type: Bug > Components: buildresult-trigger, buildresulttrigger >Affects Versions: current > Environment: Linux, 2.6.26-amd64 > debian_version 5.0.6 > Jenkins BuildResultTrigger Plug-in 0.4 > Jenkins ver. 1.440 >Reporter: S P >Assignee: gbois > Attachments: TEST-Trigger.config.xml, TEST-TRY.config-2.xml, > TEST-TRY.config.xml > > > Jenkins with the buildResultTrigger plugin is unable to trigger a job > Two jobs are setup, > 1. TEST-TRIGGER is a basic job that always passes > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:47:31 | 17/01/2012 10:47:31 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:47:31 | INFO: TEST-Trigger #7 main build > action completed: SUCCESS > > 2. TEST-TRY is a basic job configured to Monitor build results of > TEST-Trigger. This job is able to run with success when trigger manually > (from jenkins log) > INFO | jvm 2| 2012/01/17 10:48:51 | 17/01/2012 10:48:51 AM > hudson.model.Run run > INFO | jvm 2| 2012/01/17 10:48:51 | INFO: TEST-TRY #2 main build action > completed: SUCCESS > However, a success result from TEST-TRIGGER does not fire the TEST-TRY job. > Both jobs configurations are attached -- 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-13082) Breadcrumb popup menu gives javascript error on Internet Explorer 8
Alex Lehmann created JENKINS-13082: -- Summary: Breadcrumb popup menu gives javascript error on Internet Explorer 8 Key: JENKINS-13082 URL: https://issues.jenkins-ci.org/browse/JENKINS-13082 Project: Jenkins Issue Type: Bug Components: www Affects Versions: current Environment: jenkins 1.455 running on linux, client is internet explorer 8 running on windows xp also happens on ci.jenkins-ci.org (1.456 rc) with client internet explorer 8 Reporter: Alex Lehmann Priority: Blocker when moving the mouse over the breadcrumb tabs, a javascript error shows in Internet Explorer 8 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E) Timestamp: Wed, 14 Mar 2012 22:55:57 UTC Message: 'left' is null or not an object Line: 8 Char: 5672 Code: 0 URI: http://ci.jenkins-ci.org/static/6c4cb891/scripts/yui/dom/dom-min.js -- 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-12334) jenkins does not start in jboss container
[ https://issues.jenkins-ci.org/browse/JENKINS-12334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160263#comment-160263 ] Alex Lehmann edited comment on JENKINS-12334 at 3/14/12 10:52 PM: -- JENKINS-12867: this is the indentical error message, however the fix wasn't out at the time the 2nd issue was written was (Author: alexlehm): this is the indentical error message, however the fix wasn't out at the time the 2nd issue was written > jenkins does not start in jboss container > - > > Key: JENKINS-12334 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12334 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: JBoss 5.1 EAP >Reporter: Terry Sposato >Assignee: Kohsuke Kawaguchi >Priority: Blocker > Labels: jenkins > > Using latest RC version of jenkins, starting jboss up gives these errors: > 2012-01-09 16:07:06,859 INFO [org.jboss.bootstrap.microcontainer.ServerImpl] > (main) JBoss (Microcontainer) [5.1.0 (build: SVNTag=JBPAPP_5_1_0 > date=201009150028)] Started in 32s:316ms > 2012-01-09 16:07:07,305 INFO [jenkins.InitReactorRunner] (pool-14-thread-2) > Started initialization > 2012-01-09 16:07:09,553 INFO [jenkins.InitReactorRunner] (pool-14-thread-4) > Listed all plugins > 2012-01-09 16:07:13,601 INFO [jenkins.InitReactorRunner] (pool-14-thread-2) > Prepared all plugins > 2012-01-09 16:07:18,630 ERROR [STDERR] (Initializing plugin copyartifact) > SLF4J: slf4j-api 1.6.x (or later) is incompatible with this binding. > 2012-01-09 16:07:18,630 ERROR [STDERR] (Initializing plugin copyartifact) > SLF4J: Your binding is version 1.5.5 or earlier. > 2012-01-09 16:07:18,630 ERROR [STDERR] (Initializing plugin copyartifact) > SLF4J: Upgrade your binding to version 1.6.x. or 2.0.x > 2012-01-09 16:07:18,637 WARNING [hudson.ExtensionFinder$GuiceFinder] > (Initializing plugin copyartifact) Failed to instantiate. Skipping this > component > com.google.inject.ProvisionException: Guice provision errors: > 1) Error injecting constructor, java.lang.NoSuchMethodError: > org.slf4j.impl.StaticLoggerBinder.getSingleton()Lorg/slf4j/impl/StaticLoggerBinder; > at org.jenkinsci.main.modules.sshd.SSHD.(SSHD.java:40) > 1 error > at > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52) > at com.google.inject.Scopes$1$1.get(Scopes.java:59) > at > hudson.ExtensionFinder$AbstractGuiceFinder$2$1.get(ExtensionFinder.java:365) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) > at > com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:54) > at > com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:118) > at > com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:117) > at > com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87) > at > com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:259) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) > at com.google.inject.Scopes$1$1.get(Scopes.java:59) > at > hudson.ExtensionFinder$AbstractGuiceFinder$2$1.get(ExtensionFinder.java:365) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) > at > com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011) > at > com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961) > at > hudson.ExtensionFinder$AbstractGuiceFinder._find(ExtensionFinder.java:336) > at > hudson.ExtensionFinder$AbstractGuiceFinder.find(ExtensionFinder.java:327) > at hudson.ExtensionFinder._find(ExtensionFinder.java:147) > at > hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:289) > at hudson.ExtensionList.load(ExtensionList.java:278) > at hudson.ExtensionList.ensureLoaded(ExtensionList.java:231) > at hudson.ExtensionList.iterator(ExtensionList.java:138) > at jenkins.model.Jenkins.getDescriptorByType(Jenkins.java:1046) > at > hudson.plugins.copyartifact.Build
[JIRA] (JENKINS-13081) Show files that fails to parse
Bruno P. Kinoshita created JENKINS-13081: Summary: Show files that fails to parse Key: JENKINS-13081 URL: https://issues.jenkins-ci.org/browse/JENKINS-13081 Project: Jenkins Issue Type: Improvement Components: tap Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Priority: Minor with tap-plugin, currently if a tap file fails to parse for whatever reason, that is hidden away from you... it would be nice if it showed up in the TAP test list but showed as an error -- 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-13056) Obtain reference build from SCM/Trigger
[ https://issues.jenkins-ci.org/browse/JENKINS-13056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160262#comment-160262 ] Roland Schulz commented on JENKINS-13056: - I agree that the issue isn't specific to static analysis. I think any SCM history which is not linear would benefit from it. The non linear history could be branches, changeset, etc. E.g. if versions B and C are compiled after each other, and they both have A as ancestor, then it is not correct if C is using B as reference build. E.g. if B has introduced a few warnings, than build C would report those warnings as fixed. But they are not fixed because these warning still exist in the separate branch/changeset. If the threshold is set so that the count for B is above the limit, then relaying on the threshold works correctly. But in the general case it would not give the correct result. Also using the threshold makes it so that a build for version D with ancestor B doesn't report the warnings as fixed. Also it seems (but I'm highly uncertain so please correct me if I'm wrong), that also unstable builds are considered for the reference build (and only failed ones are excluded). Thus it is not enough to set the status threshold (either new or total) for unstable but one has to set it for failed if one wants to affect the reference build. Also I assume that only the status threshold and not the health threshold effect the reference build. > Obtain reference build from SCM/Trigger > --- > > Key: JENKINS-13056 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13056 > Project: Jenkins > Issue Type: Bug > Components: analysis-core, core, warnings >Reporter: Roland Schulz >Assignee: Ulli Hafner > > It would be great if the SCM would be queried for the reference build. If the > builds are not in order (e.g. because the build are triggered by code review > (e.g. Gerrit)), it doesn't make sense to use the last build as reference. The > SCM (e.g. Git) or the Trigger (e.g. Gerrit) would know the previous commit > which should be used as reference. -- 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-13080) Wipe Out Workspace fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Maxwell updated JENKINS-13080:
---
Possible
solution|https://issues.jenkins-ci.org/browse/JENKINS-13073?focusedCommentId=160259&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-160259]
> Wipe Out Workspace fails if Mapping is parametrized
> ---
>
> Key: JENKINS-13080
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13080
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>
> h2. Workaround
> If possible add a default value for the parameter like *
> h2. Details
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13080) Wipe Out Workspace fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160261#comment-160261
]
Jeff Maxwell edited comment on JENKINS-13080 at 3/14/12 9:20 PM:
-
[Possible
solution|https://issues.jenkins-ci.org/browse/JENKINS-13073?focusedCommentId=160259&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-160259]
was (Author: jmaxwell):
Possible
solution|https://issues.jenkins-ci.org/browse/JENKINS-13073?focusedCommentId=160259&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-160259]
> Wipe Out Workspace fails if Mapping is parametrized
> ---
>
> Key: JENKINS-13080
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13080
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>
> h2. Workaround
> If possible add a default value for the parameter like *
> h2. Details
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13080) Wipe Out Workspace fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Maxwell updated JENKINS-13080:
---
Description:
h2. Workaround
If possible add a default value for the parameter like *
h2. Details
Mapping setting: //depot/my-project/releases/${RELEASE}/...
//my-project-release/...
Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
processWorkspaceBeforeDeletion
SEVERE: null
com.tek42.perforce.PerforceException: Error in client specification. Error
detected at line 9. Null directory (//) not allowed in
'//depot/my-project/releases//...'.
For Command: /usr/bin/p4 -s client -i
With Data:
===
Client: my-project-release
Owner: perforce
Description: Created by perforce.
Root: opt/jenkins-data/jobs/my-project-release/workspace
Options: noallwrite clobber nocompress unlocked nomodtime rmdir
SubmitOptions: submitunchanged
LineEnd:
View:
//depot/my-project/releases//... //my-project-release/...
===
at
com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
at
hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
at
hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
at hudson.model.Run.run(Run.java:1408)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
was:
Mapping setting: //depot/my-project/releases/${RELEASE}/...
//my-project-release/...
Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
processWorkspaceBeforeDeletion
SEVERE: null
com.tek42.perforce.PerforceException: Error in client specification. Error
detected at line 9. Null directory (//) not allowed in
'//depot/my-project/releases//...'.
For Command: /usr/bin/p4 -s client -i
With Data:
===
Client: my-project-release
Owner: perforce
Description: Created by perforce.
Root: opt/jenkins-data/jobs/my-project-release/workspace
Options: noallwrite clobber nocompress unlocked nomodtime rmdir
SubmitOptions: submitunchanged
LineEnd:
View:
//depot/my-project/releases//... //my-project-release/...
===
at
com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
at
hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
at
hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
at hudson.model.Run.run(Run.java:1408)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
> Wipe Out Workspace fails if Mapping is parametrized
> ---
>
> Key: JENKINS-13080
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13080
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>
> h2. Workaround
> If possible add a default value for the parameter like *
> h2. Details
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
>
[JIRA] (JENKINS-13080) Wipe Out Workspace fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Maxwell updated JENKINS-13080:
---
Priority: Major (was: Blocker)
> Wipe Out Workspace fails if Mapping is parametrized
> ---
>
> Key: JENKINS-13080
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13080
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13080) Wipe Out Workspace fails if Mapping is parametrized
Jeff Maxwell created JENKINS-13080:
--
Summary: Wipe Out Workspace fails if Mapping is parametrized
Key: JENKINS-13080
URL: https://issues.jenkins-ci.org/browse/JENKINS-13080
Project: Jenkins
Issue Type: Bug
Components: perforce
Environment: 1.450
Perforce version 1.3.7
Reporter: Jeff Maxwell
Assignee: Rob Petti
Priority: Blocker
Mapping setting: //depot/my-project/releases/${RELEASE}/...
//my-project-release/...
Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
processWorkspaceBeforeDeletion
SEVERE: null
com.tek42.perforce.PerforceException: Error in client specification. Error
detected at line 9. Null directory (//) not allowed in
'//depot/my-project/releases//...'.
For Command: /usr/bin/p4 -s client -i
With Data:
===
Client: my-project-release
Owner: perforce
Description: Created by perforce.
Root: opt/jenkins-data/jobs/my-project-release/workspace
Options: noallwrite clobber nocompress unlocked nomodtime rmdir
SubmitOptions: submitunchanged
LineEnd:
View:
//depot/my-project/releases//... //my-project-release/...
===
at
com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
at
hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
at
hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
at hudson.model.Run.run(Run.java:1408)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160260#comment-160260
]
Jeff Maxwell edited comment on JENKINS-13073 at 3/14/12 9:04 PM:
-
Sounds like a plan.
We are going to set all our mapping parameters to default to * until the fix is
in.
was (Author: jmaxwell):
Sounds like a plan.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160260#comment-160260
]
Jeff Maxwell commented on JENKINS-13073:
Sounds like a plan.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160259#comment-160259
]
Rob Petti commented on JENKINS-13073:
-
The s#//#/.../#g approach will probably hurt some users quite a bit. Replacing
it with wildcards would make the perforce request too large for a lot of server
to handle, so I want to avoid going that route if at all possible. A better
option may be to just grab the existing client view from perforce itself, and
not change it at all.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160258#comment-160258
]
dogfood commented on JENKINS-13073:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[plugins_perforce #196|http://ci.jenkins-ci.org/job/plugins_perforce/196/]
[JENKINS-13073] use build parameters when flushing the workspace during
checkout (Revision 9ea05bacb27065a5da74d7f047dad1f64f854569)
Result = SUCCESS
Rob Petti :
Files :
* src/main/java/hudson/plugins/perforce/PerforceSCM.java
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160257#comment-160257
]
Jeff Maxwell commented on JENKINS-13073:
I was thinking sticking the build in a ThreadLocal then you could get it from
processWorkspaceBeforeDeletion.
I think the easiest solution for Clean Workspace is just to replace the
non-depot "//" instances with "/*/"
Do you want me to create another jira to track?
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11149) JNLP slave fails to connect if Anonymous has not permission READ
[ https://issues.jenkins-ci.org/browse/JENKINS-11149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160256#comment-160256 ] abayer commented on JENKINS-11149: -- Seems to me like the ideal here would be to move to using a private key approach like the CLI does (see https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI, e.g.). But if that's not viable for now...Hrm. Not sure. Lemme dig more. > JNLP slave fails to connect if Anonymous has not permission READ > > > Key: JENKINS-11149 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11149 > Project: Jenkins > Issue Type: Bug > Components: master-slave >Affects Versions: current >Reporter: Matthias Vach >Assignee: abayer > > Hi all, > I do face a problem with JNLP based windows slaves in combination with > restricted permissions of Anonymous. > If user Anonymous doesn't has READ permission granted, the JNLP slave > (converted to a windows service) fails to connect to the master. > The jenkins-slave.xml contains > > -Xrs -jar "%BASE%\slave.jar" -jnlpUrl > https://xxx:8443/hudson/computer/xxx/slave-agent.jnlp -jnlpCredentials > abcd:efgh -auth abcd:efgh > > The tomcat-users.xml contains > > > > > > > > The jenkins-slave.err.log contains > > Failing to obtain https://xxx:8443/hudson/computer/xxx/slave-agent.jnlp > java.io.IOException: Failed to load > https://xxx:8443/hudson/computer/xxx/slave-agent.jnlp: 500 Internal Server > Error > at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:228) > at hudson.remoting.Launcher.run(Launcher.java:190) > at hudson.remoting.Launcher.main(Launcher.java:166) > Waiting 10 seconds before retry > > The tomcat's localhost.2011-xx-xx.log contains > > SEVERE: Servlet.service() for servlet Stapler threw exception > hudson.security.AccessDeniedException2: anonymous is missing the Read > permission > at hudson.security.ACL.checkPermission(ACL.java:53) > at hudson.model.Node.checkPermission(Node.java:363) > at hudson.model.Hudson.getTarget(Hudson.java:3538) > ... > > The setup is as follows: > > OS: Windows 7 > Tomcat: 6.0.33 > Jenkins: 1.4.10 (also not working with 1.4.31) > JDK: 1.6.27 > Security Realm: Matrix based Security is enabled > Authorization: Delegate to servlet container > permissions of user abcd: Overall Read, Overall Administer > permissions of user Anonymous: none > -- 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-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160255#comment-160255
]
Rob Petti commented on JENKINS-13073:
-
Yes. It's a general SCM plugin api call that's normally only used from Jenkins
core, so I can't really modify it's parameters. I've just split it out into two
functions so that checkout can pass the parameters needed. Fixing the general
Clean Workspace functionality will be a bit more complicated, so I'll get to it
later.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160254#comment-160254
]
Jeff Maxwell commented on JENKINS-13073:
Is the issue that the processWorkspaceBeforeDeletion doesn't accept a build?
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160253#comment-160253
]
SCM/JIRA link daemon commented on JENKINS-13073:
Code changed in jenkins
User: Rob Petti
Path:
src/main/java/hudson/plugins/perforce/PerforceSCM.java
http://jenkins-ci.org/commit/perforce-plugin/9ea05bacb27065a5da74d7f047dad1f64f854569
Log:
[JENKINS-13073] use build parameters when flushing the workspace during
checkout
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160252#comment-160252
]
Rob Petti commented on JENKINS-13073:
-
Yeah, I'm splitting it out into two functions, rather than calling the same
function from both checkout and Clean Workspace.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160251#comment-160251
]
Jeff Maxwell commented on JENKINS-13073:
Isn't processWorkspaceBeforeDeletion called from checkout? Aren't the
parameters available there?
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11149) JNLP slave fails to connect if Anonymous has not permission READ
[ https://issues.jenkins-ci.org/browse/JENKINS-11149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] abayer reassigned JENKINS-11149: Assignee: abayer (was: Kohsuke Kawaguchi) > JNLP slave fails to connect if Anonymous has not permission READ > > > Key: JENKINS-11149 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11149 > Project: Jenkins > Issue Type: Bug > Components: master-slave >Affects Versions: current >Reporter: Matthias Vach >Assignee: abayer > > Hi all, > I do face a problem with JNLP based windows slaves in combination with > restricted permissions of Anonymous. > If user Anonymous doesn't has READ permission granted, the JNLP slave > (converted to a windows service) fails to connect to the master. > The jenkins-slave.xml contains > > -Xrs -jar "%BASE%\slave.jar" -jnlpUrl > https://xxx:8443/hudson/computer/xxx/slave-agent.jnlp -jnlpCredentials > abcd:efgh -auth abcd:efgh > > The tomcat-users.xml contains > > > > > > > > The jenkins-slave.err.log contains > > Failing to obtain https://xxx:8443/hudson/computer/xxx/slave-agent.jnlp > java.io.IOException: Failed to load > https://xxx:8443/hudson/computer/xxx/slave-agent.jnlp: 500 Internal Server > Error > at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:228) > at hudson.remoting.Launcher.run(Launcher.java:190) > at hudson.remoting.Launcher.main(Launcher.java:166) > Waiting 10 seconds before retry > > The tomcat's localhost.2011-xx-xx.log contains > > SEVERE: Servlet.service() for servlet Stapler threw exception > hudson.security.AccessDeniedException2: anonymous is missing the Read > permission > at hudson.security.ACL.checkPermission(ACL.java:53) > at hudson.model.Node.checkPermission(Node.java:363) > at hudson.model.Hudson.getTarget(Hudson.java:3538) > ... > > The setup is as follows: > > OS: Windows 7 > Tomcat: 6.0.33 > Jenkins: 1.4.10 (also not working with 1.4.31) > JDK: 1.6.27 > Security Realm: Matrix based Security is enabled > Authorization: Delegate to servlet container > permissions of user abcd: Overall Read, Overall Administer > permissions of user Anonymous: none > -- 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-12889) Jenkins "Workspace" presents "Run a build" even when Builds are Disabled
[ https://issues.jenkins-ci.org/browse/JENKINS-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160250#comment-160250 ] SCM/JIRA link daemon commented on JENKINS-12889: Code changed in jenkins User: Andrew Bayer Path: core/src/main/resources/hudson/model/AbstractItem/noWorkspace.jelly http://jenkins-ci.org/commit/jenkins/9ffcbba5e96ea508419171c0ff1d18a5fdc88c4a Log: Merge pull request #404 from onemanbucket/master fixes: JENKINS-12889 Jenkins "Workspace" presents "Run a build" even when Builds are Disabled > Jenkins "Workspace" presents "Run a build" even when Builds are Disabled > > > Key: JENKINS-12889 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12889 > Project: Jenkins > Issue Type: Improvement > Components: core >Affects Versions: current > Environment: Jenkins: 1.451 > Perforce SCM Plugin: 1.3.8 > tomcat: 6.0.33-1.26 >Reporter: Colin Johnson >Priority: Trivial > Attachments: jenkins - Unable to Build because Build Disabled.txt > > > Summary: Clicking "Run a build to have Jenkins create a workspace" is > presented to user in Workspace, and clicking on link presents error. > Steps to reproduce: > 1. Disable Job, Do Not Initial Initiate Perforce Sync and let > 2. Navigate -> Jenkins -> Job (job must be using Perforce as SCM) -> Workspace > Note: in step two, workspace contains text declaring the following: > Error: no workspace > A project won't have any workspace until at least one build is performed. > Run a build to have Jenkins create a workspace. > 3. Click link "Run a build to have Jenkins create a workspace." > Error Returned: > java.io.IOException: $JOBNAME is not buildable. -- 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-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160249#comment-160249
]
Rob Petti commented on JENKINS-13073:
-
Ah, so your default is set to nothing? That would explain it. The clean
workspace option does not run as a build, and as such needs to use the default
parameters.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160248#comment-160248
]
Jeff Maxwell commented on JENKINS-13073:
In the Clean workspace button scenario run the getDefaultSubstitutions but
also replace all non depot // references with either /*/ or /.../
I have tested both and they appear to work.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160246#comment-160246
]
Jeff Maxwell commented on JENKINS-13073:
Just a string
I think the issue is caused by 2647:
substituteParameters(projectPath,getDefaultSubstitutions(project))
To make it work during a build this needs to substitute the build parameters,
however this does not fix the Clean Workspace button.
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13079) memory error watching console of a verbose job (20M log)
[ https://issues.jenkins-ci.org/browse/JENKINS-13079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160247#comment-160247 ] Greg Moncreaff commented on JENKINS-13079: -- After this the Jenkins server process became non-responsive with repeated exceptions caused by Caused by: java.lang.OutOfMemoryError: PermGen space top says: top - 19:22:45 up 91 days, 6:59, 19 users, load average: 0.94, 1.04, 1.53 Tasks: 219 total, 1 running, 217 sleeping, 0 stopped, 1 zombie Cpu(s): 17.4%us, 3.0%sy, 0.0%ni, 77.9%id, 0.8%wa, 0.1%hi, 0.7%si, 0.0%st Mem: 12160680k total, 11971892k used, 188788k free,78332k buffers Swap: 14386168k total, 203756k used, 14182412k free, 7570940k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 13195 ... 16 0 3759m 2.8g 18m S 99.9 23.9 306:44.80 java -jar jenkins.war --httpPort=8080 --ajp13Port=8009 > memory error watching console of a verbose job (20M log) > - > > Key: JENKINS-13079 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13079 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Greg Moncreaff > > Mar 14, 2012 6:53:07 PM winstone.Logger logInternal > SEVERE: Error while serving > http://.../view/All/job/.../10/logText/progressiveHtml > java.lang.reflect.InvocationTargetException > at sun.reflect.GeneratedMethodAccessor5016.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) > at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) > at > org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) > at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) > at > org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) > at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) > at > org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) > at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) > 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:563) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) > 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:563) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) > at org.kohsuke.stapler.Stapler.service(Stapler.java:159) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) > at > winstone.ServletConfiguration.execute(ServletConfiguration.java:248) > at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) > at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) > at > hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) > at > hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66) > at > hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) > at > hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) > at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) > at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) > at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) > at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) > at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) > at > hudson.securit
[JIRA] (JENKINS-13079) memory error watching console of a verbose job (20M log)
Greg Moncreaff created JENKINS-13079: Summary: memory error watching console of a verbose job (20M log) Key: JENKINS-13079 URL: https://issues.jenkins-ci.org/browse/JENKINS-13079 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: Greg Moncreaff Mar 14, 2012 6:53:07 PM winstone.Logger logInternal SEVERE: Error while serving http://.../view/All/job/.../10/logText/progressiveHtml java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor5016.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) 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:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) 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:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) at org.kohsuke.stapler.Stapler.service(Stapler.java:159) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.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:61) at hudson.secu
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Petti reassigned JENKINS-13073:
---
Assignee: Rob Petti
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Assignee: Rob Petti
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160245#comment-160245
]
Rob Petti commented on JENKINS-13073:
-
What type of build parameter is RELEASE?
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13010) Impossible to use JavaScript at view's description
[ https://issues.jenkins-ci.org/browse/JENKINS-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kohsuke Kawaguchi resolved JENKINS-13010. - Assignee: Kohsuke Kawaguchi Resolution: Fixed I wrote [a plugin|https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=60915753] to accomodate this use case. > Impossible to use JavaScript at view's description > -- > > Key: JENKINS-13010 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13010 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Daniel Tkatch >Assignee: Kohsuke Kawaguchi > > # click "Edit view" > # enter a into the Description field that allows HTML and > save > -> > #
[JIRA] (JENKINS-8734) Hudson Translation assistance can not post localisations, responds with Status Code 500
[
https://issues.jenkins-ci.org/browse/JENKINS-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
evernat resolved JENKINS-8734.
--
Resolution: Fixed
I have reproduced the same issue in the past, and recently I have seen it work.
In fact, this issue was fixed in the translation assistance plugin v1.7 (August
2011), according to the plugin page:
https://wiki.jenkins-ci.org/display/JENKINS/Translation+Assistance+Plugin
> Hudson Translation assistance can not post localisations, responds with
> Status Code 500
> ---
>
> Key: JENKINS-8734
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8734
> Project: Jenkins
> Issue Type: Bug
> Components: plugin
> Environment: Jenkins 1.396, Hudson translation assistance 1.5
>Reporter: redsolo
>
> Im getting the Status Code 500 when posting localizations.
> Steps to reproduce:
> 1. Open a translation dialog
> 2. Change anything (swedish locale)
> 3. Submit
> Expected outcome:
> Localisation is posted
> Actual outcome:
> Got an dialog stating;
> Status Code: 500
> Exception:
> Stacktrace:
> net.sf.json.JSONException: A JSONObject text must begin with '{' at character
> 1 of true
> at net.sf.json.util.JSONTokener.syntaxError(JSONTokener.java:512)
> at net.sf.json.JSONObject._fromJSONTokener(JSONObject.java:839)
> at net.sf.json.JSONObject._fromString(JSONObject.java:1060)
> at net.sf.json.JSONObject.fromObject(JSONObject.java:176)
> at net.sf.json.JSONObject.fromObject(JSONObject.java:147)
> at
> org.kohsuke.stapler.RequestImpl.getSubmittedForm(RequestImpl.java:774)
> at
> hudson.plugins.translation.L10nDecorator.doSubmit(L10nDecorator.java:170)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
> at
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:102)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:562)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:640)
> at org.kohsuke.stapler.MetaClass$13.dispatch(MetaClass.java:382)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:562)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:640)
> at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:204)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:562)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:640)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:478)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:160)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
> at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
> 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.remem
[JIRA] (JENKINS-13078) Multijob Plugin looses a hierarchical view at the multijob project page when it has upstream project(s)
Tetiana Tvardovska created JENKINS-13078: Summary: Multijob Plugin looses a hierarchical view at the multijob project page when it has upstream project(s) Key: JENKINS-13078 URL: https://issues.jenkins-ci.org/browse/JENKINS-13078 Project: Jenkins Issue Type: Bug Components: core Reporter: Tetiana Tvardovska When multijob project is linked to another upstream project, Multijob Plugin stops showing an hierarchical view of used jobs. But, when the up link is removed, the hierarchical view of used jobs appears again. -- 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-13015) "Custom xcodebuild arguments" field doesn't save arguments
[ https://issues.jenkins-ci.org/browse/JENKINS-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160242#comment-160242 ] Sam Ferrise commented on JENKINS-13015: --- Has anyone been able to find a work around for this issue? > "Custom xcodebuild arguments" field doesn't save arguments > -- > > Key: JENKINS-13015 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13015 > Project: Jenkins > Issue Type: Bug > Components: xcode >Affects Versions: current > Environment: Jenkins 1.454, xCode integration plugin 1.3, OS: Ubuntu > server 10.04 >Reporter: Alexander Khozya > > NOTE: this issue causes broken builds on some app configurations > 1. Create freestyle job > 2. Setup project > 3. Enter something into "Custom xcodebuild arguments" for example "-arch i386" > 4. Apply and Save > 5. Don't go anywhere from this page and click Build - project will build OK > 6. Go to main page > 7. Go to project>Configure > Actual result: "Custom xcodebuild arguments" field is empty > Expected result: there is "-arch i386" parameter -- 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-13077) Repo plugin should have an option to wipe out workspace
Sam Xiao created JENKINS-13077: -- Summary: Repo plugin should have an option to wipe out workspace Key: JENKINS-13077 URL: https://issues.jenkins-ci.org/browse/JENKINS-13077 Project: Jenkins Issue Type: New Feature Components: repo Reporter: Sam Xiao Repo plugin should have an option to wipe out workspace. We need this feature to ensure the build is always start fresh and clean. Or put in "git clean -xdf" option on each repositories and clean it specifically. -- 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-13037) TestLink Plugin with jUnit
[ https://issues.jenkins-ci.org/browse/JENKINS-13037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160241#comment-160241 ] Bruno P. Kinoshita commented on JENKINS-13037: -- Hi Bogdan, glad to hear that that worked. > Is there a way to add the status of the methods of a testcase in a report? That's doable, here's the issue. https://issues.jenkins-ci.org/browse/JENKINS-13076 A new release will be cut as soon as I finish coding/testing this new feature. Probably before the weekend. Cheers Bruno > TestLink Plugin with jUnit > -- > > Key: JENKINS-13037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13037 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current > Environment: Ubuntu 10.04 >Reporter: Bogdan Girbea >Assignee: Bruno P. Kinoshita > Labels: jenkins > > Hello > I am using the 3.1 testlink plugin. I am running a test class, with 4 tests > using JUnit 4.8.One of the 4 tests throws an error and still the testlink > report marks the test class as passed. > If needed i can attach the configurations and/or the results.. > Thank you! -- 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-13076) Improve test notes created when updating a test case in TestLink
Bruno P. Kinoshita created JENKINS-13076: Summary: Improve test notes created when updating a test case in TestLink Key: JENKINS-13076 URL: https://issues.jenkins-ci.org/browse/JENKINS-13076 Project: Jenkins Issue Type: Improvement Components: testlink Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Priority: Minor The current version of the plug-in is not including notes. For each result seeking strategy, there are different types of information that may be important to the end user. And it's damn boring having to open the XML/TAP files to see what happened :) -- 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-13075) Subversion plugin should allow environment variables in the Repository URL
Leandro Siqueira created JENKINS-13075: -- Summary: Subversion plugin should allow environment variables in the Repository URL Key: JENKINS-13075 URL: https://issues.jenkins-ci.org/browse/JENKINS-13075 Project: Jenkins Issue Type: Improvement Components: subversion Affects Versions: current Reporter: Leandro Siqueira Priority: Trivial Attachments: svn.JPG I have a parametrized build with a Choice parameter (named Branch) that shows a list of existing branches. When I put this environment variable in the Repository URL Jenkins shows an error message (see attached image), but the build works as expected. It would be nice if we had an option to allow the Repository URL to contain a environment variable, so in this case no error message would appear. -- 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-13074) when using "Latest successful build", viewing build parameters does not display build number
David Chou created JENKINS-13074: Summary: when using "Latest successful build", viewing build parameters does not display build number Key: JENKINS-13074 URL: https://issues.jenkins-ci.org/browse/JENKINS-13074 Project: Jenkins Issue Type: Bug Components: copyartifact Affects Versions: current Reporter: David Chou Assignee: Alan Harder Attachments: parameterbySelectingSpecificBuild.PNG, parametersbySelectingLatestSuccesfulBuild.PNG Using Copy Artifact Plugin version 1.21 1. Use the 'Build Selector for Copy Artifact' as a build parameter 2. Choose "Latest successful build" 3. Build the project 4. View the project's parameters ( http://jenkins-instance///parameters/ ) Expected it to show which buildNumber it chose, as it does when you use "Specific build" (attachment: parameterbySelectingSpecificBuild.PNG) Actual, shows "StatusBuildSelector" (attachment: parametersbySelectingLatestSuccesfulBuild.PNG) I'd be extremely helpful to see which build number was selected in the parameters when choosing "Latest successful build" [ I do know about the "Copied 1 artifact from "foo-project" build number 123" ] 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-11698) NPE occurs for a dependency graph that is not the default view
[ https://issues.jenkins-ci.org/browse/JENKINS-11698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160240#comment-160240 ] Paul Reeder commented on JENKINS-11698: --- I have the same problem with this stack trace: java.lang.NullPointerException at hudson.model.View.getDynamic(View.java:331) 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.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:371) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:233) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) at org.kohsuke.stapler.Stapler.service(Stapler.java:159) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:249) at winstone.RequestDispatcher.forward(RequestDispatcher.java:335) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) at org.hudsonci.servlets.internal.ServletRegistrationFilterAdapter.doFilter(ServletRegistrationFilterAdapter.java:180) at org.hudsonci.servlets.internal.ServletRegistrationFilterAdapter.doFilter(ServletRegistrationFilterAdapter.java:148) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97) at org.hudsonci.servlets.internal.ServletRegistrationFilterAdapter.doFilter(ServletRegistrationFilterAdapter.java:180) at org.hudsonci.servlets.internal.ServletRegistrationFilterAdapter.doFilter(ServletRegistrationFilterAdapter.java:148) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:52) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) at winstone.FilterConfiguration.execute(FilterConfiguration.java:195) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:195) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:195) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:195) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150) at java.lang.Thread.run(Unknown Source) > NPE occurs for a dependency graph that is not the default view > -- > > Key: JENKINS-11698 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11698 > Project: Jenkins > Issue Type: Bug > Components: depgraph-view > Environment: RHEL 5.5, Jenkins 1.438, Dependency Graph plugin 0.2 >Reporter: tk694h >Assignee: wolfs > Attachments: jenkins.log > > > The dependency graph works fine for the default view. However for any other > view a NPE occurs. An NPE occurs even for the "All" view. -- 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.at
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
[
https://issues.jenkins-ci.org/browse/JENKINS-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Maxwell updated JENKINS-13073:
---
Environment:
1.450
Perforce version 1.3.7
was:1.450
> Clean Workspace Before Each Build fails if Mapping is parametrized
> --
>
> Key: JENKINS-13073
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: 1.450
> Perforce version 1.3.7
>Reporter: Jeff Maxwell
>Priority: Blocker
>
> Mapping setting: //depot/my-project/releases/${RELEASE}/...
> //my-project-release/...
> Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
> processWorkspaceBeforeDeletion
> SEVERE: null
> com.tek42.perforce.PerforceException: Error in client specification. Error
> detected at line 9. Null directory (//) not allowed in
> '//depot/my-project/releases//...'.
> For Command: /usr/bin/p4 -s client -i
> With Data:
> ===
> Client: my-project-release
> Owner: perforce
> Description: Created by perforce.
> Root: opt/jenkins-data/jobs/my-project-release/workspace
> Options: noallwrite clobber nocompress unlocked nomodtime rmdir
> SubmitOptions: submitunchanged
> LineEnd:
> View:
> //depot/my-project/releases//... //my-project-release/...
> ===
> at
> com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
> at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
> at
> hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
> at
> hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
> at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
> at hudson.model.Run.run(Run.java:1408)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13073) Clean Workspace Before Each Build fails if Mapping is parametrized
Jeff Maxwell created JENKINS-13073:
--
Summary: Clean Workspace Before Each Build fails if Mapping is
parametrized
Key: JENKINS-13073
URL: https://issues.jenkins-ci.org/browse/JENKINS-13073
Project: Jenkins
Issue Type: Bug
Components: perforce
Environment: 1.450
Reporter: Jeff Maxwell
Priority: Blocker
Mapping setting: //depot/my-project/releases/${RELEASE}/...
//my-project-release/...
Mar 14, 2012 12:17:36 PM hudson.plugins.perforce.PerforceSCM
processWorkspaceBeforeDeletion
SEVERE: null
com.tek42.perforce.PerforceException: Error in client specification. Error
detected at line 9. Null directory (//) not allowed in
'//depot/my-project/releases//...'.
For Command: /usr/bin/p4 -s client -i
With Data:
===
Client: my-project-release
Owner: perforce
Description: Created by perforce.
Root: opt/jenkins-data/jobs/my-project-release/workspace
Options: noallwrite clobber nocompress unlocked nomodtime rmdir
SubmitOptions: submitunchanged
LineEnd:
View:
//depot/my-project/releases//... //my-project-release/...
===
at
com.tek42.perforce.parse.AbstractPerforceTemplate.saveToPerforce(AbstractPerforceTemplate.java:261)
at com.tek42.perforce.parse.Workspaces.saveWorkspace(Workspaces.java:69)
at
hudson.plugins.perforce.PerforceSCM.saveWorkspaceIfDirty(PerforceSCM.java:1373)
at
hudson.plugins.perforce.PerforceSCM.processWorkspaceBeforeDeletion(PerforceSCM.java:2353)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:575)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
at hudson.model.Run.run(Run.java:1408)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13072) Add option to run Site Monitor as a build step
Tetiana Tvardovska created JENKINS-13072: Summary: Add option to run Site Monitor as a build step Key: JENKINS-13072 URL: https://issues.jenkins-ci.org/browse/JENKINS-13072 Project: Jenkins Issue Type: New Feature Components: sitemonitor Reporter: Tetiana Tvardovska Assignee: cliffano Priority: Minor It would be nice to have an option to run Site Monitor as a build step, not only as a post-build action. -- 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-12250) Critical block can not be added into conditional step
[ https://issues.jenkins-ci.org/browse/JENKINS-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160239#comment-160239 ] Oleksandr Popov commented on JENKINS-12250: --- no it is not working... Is it normal - I've uploaded .hpi file via Jenkins interface and version of Exclusion plugin still 0.6? > Critical block can not be added into conditional step > - > > Key: JENKINS-12250 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12250 > Project: Jenkins > Issue Type: Bug > Components: conditional-buildstep, exclusion > Environment: Jenkins 1.445 > Jenkins Exclusion Plug-in 0.6 > conditional-buildstep 0.2 >Reporter: Oleksandr Popov >Assignee: Anthony Roux >Priority: Critical > Attachments: critical-block.PNG > > > I'm not able to add critical block into conditional step. See screen-shot for > details -- 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-13007) Git plugin cannot find revision to build on Windows
[ https://issues.jenkins-ci.org/browse/JENKINS-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160238#comment-160238 ] Martin-Louis Bright edited comment on JENKINS-13007 at 3/14/12 3:34 PM: This happens on Centos 6.2 (Jenkins master) and Windows 7 (Jenkins slave) too. And downgrading also fixes the issue on these platforms. was (Author: mlbright): This happens on Centos 6.2 (Jenkins master) and Windows 7 (Jenkins slave) too. > Git plugin cannot find revision to build on Windows > --- > > Key: JENKINS-13007 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13007 > Project: Jenkins > Issue Type: Bug > Components: git > Environment: Windows 2008 Server 64 Bit > NTFS >Reporter: ritzmann >Assignee: Nicolas De Loof >Priority: Critical > > After we upgraded the Git plugin from 1.1.14 to 1.1.16, all our builds on > Windows build slaves started failing like this: > Started by user anonymous > Building remotely on win-slave1 in workspace d:\hudson\workspace\my-app > Checkout:my-app / d:\hudson\workspace\my-app - > hudson.remoting.Channel@95ff886:win-slave1 > Using strategy: Default > Last Built Revision: Revision e00e2c1328a011ca99980e0ffd90f7534b34 > (origin/master) > Checkout:my-app / d:\hudson\workspace\my-app - > hudson.remoting.LocalChannel@470a4b80 > Fetching changes from 1 remote Git repository > Fetching upstream changes from d:\hudson\shared\repo.git > ERROR: Couldn't find any revision to build. Verify the repository and branch > configuration for this job. > The builds on our Linux slaves are not affected. Wiping the workspaces on the > Windows slaves did not help. Both clones and checkouts/updates seem to fail > with the same error. Downgrading back to 1.1.14 made the Windows builds work > again. -- 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-13007) Git plugin cannot find revision to build on Windows
[ https://issues.jenkins-ci.org/browse/JENKINS-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160238#comment-160238 ] Martin-Louis Bright commented on JENKINS-13007: --- This happens on Centos 6.2 (Jenkins master) and Windows 7 (Jenkins slave) too. > Git plugin cannot find revision to build on Windows > --- > > Key: JENKINS-13007 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13007 > Project: Jenkins > Issue Type: Bug > Components: git > Environment: Windows 2008 Server 64 Bit > NTFS >Reporter: ritzmann >Assignee: Nicolas De Loof >Priority: Critical > > After we upgraded the Git plugin from 1.1.14 to 1.1.16, all our builds on > Windows build slaves started failing like this: > Started by user anonymous > Building remotely on win-slave1 in workspace d:\hudson\workspace\my-app > Checkout:my-app / d:\hudson\workspace\my-app - > hudson.remoting.Channel@95ff886:win-slave1 > Using strategy: Default > Last Built Revision: Revision e00e2c1328a011ca99980e0ffd90f7534b34 > (origin/master) > Checkout:my-app / d:\hudson\workspace\my-app - > hudson.remoting.LocalChannel@470a4b80 > Fetching changes from 1 remote Git repository > Fetching upstream changes from d:\hudson\shared\repo.git > ERROR: Couldn't find any revision to build. Verify the repository and branch > configuration for this job. > The builds on our Linux slaves are not affected. Wiping the workspaces on the > Windows slaves did not help. Both clones and checkouts/updates seem to fail > with the same error. Downgrading back to 1.1.14 made the Windows builds work > again. -- 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-13070) Scrollbar in HTML publisher due to 100% height on div/iframe
[ https://issues.jenkins-ci.org/browse/JENKINS-13070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mcrooney reassigned JENKINS-13070: -- Assignee: (was: mcrooney) This would be good to fix, I'd encourage you to give it a shot via the inspector in Chrome or otherwise, and submit a patch if it works in Firefox and Chrome. > Scrollbar in HTML publisher due to 100% height on div/iframe > > > Key: JENKINS-13070 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13070 > Project: Jenkins > Issue Type: Bug > Components: htmlpublisher >Reporter: Christian Weiske >Priority: Minor > Attachments: 2012-03-14 jenkins html publisher scrollbar.png > > > The HTML publisher embeds the to-be published documents in an iframe below > the "Back to " link. The iframe and the div around it have 100% > height, which *always* cause a scrollbar to appear, even when it's not needed. > See the screenshot for an example. > I think the 100% height of the div needs to be removed. -- 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-13071) Add recognition of environment variables and project parameters
Tetiana Tvardovska created JENKINS-13071:
Summary: Add recognition of environment variables and project
parameters
Key: JENKINS-13071
URL: https://issues.jenkins-ci.org/browse/JENKINS-13071
Project: Jenkins
Issue Type: Improvement
Components: sitemonitor
Reporter: Tetiana Tvardovska
Assignee: cliffano
It would be much more useful if Site Monitor plugin would recognize project
parameters values and environment variables and substitute their values when
site defined with syntax like:
$SERVER
http://${IP}
${PROTOCOL}://${SERVER}
--
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-13007) Git plugin cannot find revision to build on Windows
[ https://issues.jenkins-ci.org/browse/JENKINS-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160236#comment-160236 ] Curt Moore commented on JENKINS-13007: -- I'm also using Windows 2008 R2 64 bit for my build nodes and can also confirm that downgrading to 1.1.15 resolves the issue. Can we bump this to a higher priority? > Git plugin cannot find revision to build on Windows > --- > > Key: JENKINS-13007 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13007 > Project: Jenkins > Issue Type: Bug > Components: git > Environment: Windows 2008 Server 64 Bit > NTFS >Reporter: ritzmann >Assignee: Nicolas De Loof >Priority: Critical > > After we upgraded the Git plugin from 1.1.14 to 1.1.16, all our builds on > Windows build slaves started failing like this: > Started by user anonymous > Building remotely on win-slave1 in workspace d:\hudson\workspace\my-app > Checkout:my-app / d:\hudson\workspace\my-app - > hudson.remoting.Channel@95ff886:win-slave1 > Using strategy: Default > Last Built Revision: Revision e00e2c1328a011ca99980e0ffd90f7534b34 > (origin/master) > Checkout:my-app / d:\hudson\workspace\my-app - > hudson.remoting.LocalChannel@470a4b80 > Fetching changes from 1 remote Git repository > Fetching upstream changes from d:\hudson\shared\repo.git > ERROR: Couldn't find any revision to build. Verify the repository and branch > configuration for this job. > The builds on our Linux slaves are not affected. Wiping the workspaces on the > Windows slaves did not help. Both clones and checkouts/updates seem to fail > with the same error. Downgrading back to 1.1.14 made the Windows builds work > again. -- 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-12306) Publish summary of monitored urls to project page
[ https://issues.jenkins-ci.org/browse/JENKINS-12306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160235#comment-160235 ] Tetiana Tvardovska commented on JENKINS-12306: -- It would be usefull for us also for continuous integration process. Now, plugin results (Site Monitor Report) are shown on the build page only. Its results are not shown in the main project(job) page. Is it possible to have an option to *publish* _Site Monitor Report_ with the last build results? Using plugin version 0.4, Jenkins ver. 1.454. > Publish summary of monitored urls to project page > -- > > Key: JENKINS-12306 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12306 > Project: Jenkins > Issue Type: New Feature > Components: sitemonitor >Reporter: G. Ann Campbell >Assignee: cliffano > > It would be nice if I could (choose to?) get a list of monitored URL's - > linked - displayed at the project level -- 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-12235) FATAL, Unable to delete script file, IOException2, remote file operation failed, unexpected termination of channel
[ https://issues.jenkins-ci.org/browse/JENKINS-12235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160234#comment-160234 ] brianharris commented on JENKINS-12235: --- Suspected duplicate: JENKINS-6817 > FATAL, Unable to delete script file, IOException2, remote file operation > failed, unexpected termination of channel > -- > > Key: JENKINS-12235 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12235 > Project: Jenkins > Issue Type: Bug > Components: core, master-slave >Reporter: Ghenadie Dumitru > Attachments: jenkins_fatal_io_exception.txt > > > Below is the stacktrace. > It happened when I ran two jobs on a master. After running a while, both jobs > crashed with this exception. > I think this might be caused by a small flip-flop connectivity of the > network, but I didn't noticed any disconnection. > Another cause may be the huge load of jenkins: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > > > 25942 hudson15 0 6902m 5.8g 5720 S 0.3 74.3 401:22.30 java > Does the jenkins runs its own garbage collector at some specified time? > We have to restart every few days because it's getting slower and slower > until hangs out. > FATAL: Unable to delete script file /tmp/hudson8303731085225956739.sh > hudson.util.IOException2: remote file operation failed: > /tmp/hudson8303731085225956739.sh at > hudson.remoting.Channel@30e472f4:build@autom-1 > at hudson.FilePath.act(FilePath.java:781) > at hudson.FilePath.act(FilePath.java:767) > at hudson.FilePath.delete(FilePath.java:1022) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:695) > 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:461) > at hudson.model.Run.run(Run.java:1404) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) > Caused by: hudson.remoting.ChannelClosedException: channel is already closed > at hudson.remoting.Channel.send(Channel.java:499) > at hudson.remoting.Request.call(Request.java:110) > at hudson.remoting.Channel.call(Channel.java:681) > at hudson.FilePath.act(FilePath.java:774) > ... 13 more > Caused by: java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel > hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) > at $Proxy29.join(Unknown Source) > at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:859) > at hudson.Launcher$ProcStarter.join(Launcher.java:345) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:695) > 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:461) > at hudson.model.Run.run(Run.java:1404) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.jav
[JIRA] (JENKINS-1948) intermittent: fails to remove temporary file on remote.
[ https://issues.jenkins-ci.org/browse/JENKINS-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160233#comment-160233 ] brianharris commented on JENKINS-1948: -- Suspected duplicate: JENKINS-6817 > intermittent: fails to remove temporary file on remote. > --- > > Key: JENKINS-1948 > URL: https://issues.jenkins-ci.org/browse/JENKINS-1948 > Project: Jenkins > Issue Type: Bug > Components: other >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: bll > Attachments: jenkins_fatal_io_exception.txt > > > Another intermittent problem. > Master is linux, target is freebsd 4.9. > FATAL: Unable to delete script file /var/tmp/hudson60616.sh > hudson.util.IOException2: remote file operation failed > at hudson.FilePath.act(FilePath.java:313) > at hudson.FilePath.delete(FilePath.java:510) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:70) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:34) > at hudson.model.Build$RunnerImpl.build(Build.java:130) > at hudson.model.Build$RunnerImpl.doRun(Build.java:105) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:231) > at hudson.model.Run.run(Run.java:756) > at hudson.model.Build.run(Build.java:85) > at hudson.model.ResourceController.execute(ResourceController.java:70) > at hudson.model.Executor.run(Executor.java:82) > Caused by: java.io.IOException: already closed > at hudson.remoting.Channel.send(Channel.java:316) > at hudson.remoting.Request.call(Request.java:81) > at hudson.remoting.Channel.call(Channel.java:390) > at hudson.FilePath.act(FilePath.java:310) > ... 10 more > Build was aborted > FATAL: null > java.lang.NullPointerException > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:78) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:309) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:297) > at hudson.model.Build$RunnerImpl.post2(Build.java:118) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:282) > at hudson.model.Run.run(Run.java:774) > at hudson.model.Build.run(Build.java:85) > at hudson.model.ResourceController.execute(ResourceController.java:70) > at hudson.model.Executor.run(Executor.java:82) -- 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-10585) Radiator View does show builds with test-failure as red rather than yellow on Webkit and Firefox
[
https://issues.jenkins-ci.org/browse/JENKINS-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160232#comment-160232
]
Michał Chojaczyk commented on JENKINS-10585:
Hi,
what about change it with this way:
http://www.red-team-design.com/css3-webkit-gradient-support-updated
how to check-in the corrected code? I've log/pass accepted by svn server but
while committing there is problem. Can someone to test access?
BR
Michał
> Radiator View does show builds with test-failure as red rather than yellow on
> Webkit and Firefox
>
>
> Key: JENKINS-10585
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10585
> Project: Jenkins
> Issue Type: Bug
> Components: radiatorview
>Affects Versions: current
> Environment: * WebKit Browsers (like Chrome), Firefox; Internet
> Explorer not affected
> * Radiator View Plugin 1.13
>Reporter: Mark Michaelis
>Assignee: howama
> Attachments: BGColorTestFailures-JENKINS-10585.svn.diff
>
>
> With Version 1.13 of the Radiator View Plugin Builds with Test Failures are
> not shown as yellow anylonger but are red. This is true for all WebKit
> browsers and Firefox browsers because of this CSS entry:
> {noformat}
> .failing {
> background-image: -webkit-gradient(...red...);
> background-image: -moz-linear-gradient(...red...);
> }
> {noformat}
> and the HTML source for reading:
> {code:xml}
> Failed
> Build
> Failed
> Tests
> {code}
> Thus the gradient overrides the background-color and both jobs are shown as
> being red.
--
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-12216) Rake/Ruby build step is not available in actions for other plugins
[
https://issues.jenkins-ci.org/browse/JENKINS-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160231#comment-160231
]
Dieter De Meyer commented on JENKINS-12216:
---
I also fixed this issue in the ruby-plugin and sent a pull request to the
Github repository.
More info at https://github.com/jenkinsci/ruby-plugin/pull/1
> Rake/Ruby build step is not available in actions for other plugins
> --
>
> Key: JENKINS-12216
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12216
> Project: Jenkins
> Issue Type: Bug
> Components: rake, ruby
>Affects Versions: current
> Environment: Jenkins 1.420 & 1.444
> Rake plugin 1.7.7
> Promoted build plugin 2.4
> Conditional buildstep plugin 0.3
>Reporter: Kristof Willaert
>Assignee: Dieter De Meyer
>Priority: Minor
>
> With the Rake plugin installed, a rake build step appears in the list of
> build steps. However, when also using the promoted builds plugin, the list of
> actions to be executed with a promoted build does not contain the rake build
> step.
> Upon investigation, the list of possible actions in the promoted builds
> plugin gets compiled using the following condition:
> {code}
> BuildStepDescriptor bsd = (BuildStepDescriptor) d;
> if(bsd.isApplicable(PromotionProcess.class))
> list.add(d);
> {code}
> (in
> promoted-builds-plugin/src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java)
> I guess the reason why the Rake builder does not appear in the list of
> actions, is because the RakeDescriptor class
> extends the Descriptor class instead of the
> BuildStepDescriptor class:
> {code}
> public static final class RakeDescriptor extends Descriptor {
> {code}
> (in rake-plugin/src/main/java/hudson/plugins/rake/Rake.java)
> My guess is that adding an
> {code}
> import hudson.tasks.BuildStepDescriptor;
> {code}
> and changing the RakeDescriptor class to:
> {code}
> public static final class RakeDescriptor extends BuildStepDescriptor
> {
> {code}
> might fix this.
> I have to say I am a complete Java newbie, and the Jenkins code is unknown to
> me, so
> I might be way off.
--
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-13070) Scrollbar in HTML publisher due to 100% height on div/iframe
Christian Weiske created JENKINS-13070: -- Summary: Scrollbar in HTML publisher due to 100% height on div/iframe Key: JENKINS-13070 URL: https://issues.jenkins-ci.org/browse/JENKINS-13070 Project: Jenkins Issue Type: Bug Components: htmlpublisher Reporter: Christian Weiske Assignee: mcrooney Priority: Minor Attachments: 2012-03-14 jenkins html publisher scrollbar.png The HTML publisher embeds the to-be published documents in an iframe below the "Back to " link. The iframe and the div around it have 100% height, which *always* cause a scrollbar to appear, even when it's not needed. See the screenshot for an example. I think the 100% height of the div needs to be removed. -- 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-13069) add information about job deletion to All Configuration History
Martin Roth created JENKINS-13069: - Summary: add information about job deletion to All Configuration History Key: JENKINS-13069 URL: https://issues.jenkins-ci.org/browse/JENKINS-13069 Project: Jenkins Issue Type: Improvement Components: jobconfighistory Reporter: Martin Roth now on root level the only changes we can see are job creation and modification. there no way to quickly realize that job has been deleted, but it could come handy. -- 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-10319) Ability to change the name "Compiler" as seen in a lot of the displays
[ https://issues.jenkins-ci.org/browse/JENKINS-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160229#comment-160229 ] Ulli Hafner commented on JENKINS-10319: --- Update: I now finished the prototype which creates a new action for each parser step. Seems to run smoothly:-) Now I need to provide a way to navigate to the individual results (since there are multiple graphs now). I will also change all analysis plug-ins (not only the warnings plug-in) to use that feature, so this still will need some more time. In the end, implementing that feature will provide a much simpler way to add and visualize new parsers. Currently I'm having the following properties for each parser: - ID - Name - Icon Is there anything else that should be shown for each parser? > Ability to change the name "Compiler" as seen in a lot of the displays > -- > > Key: JENKINS-10319 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10319 > Project: Jenkins > Issue Type: New Feature > Components: warnings >Reporter: Nigel Robbins >Assignee: Ulli Hafner >Priority: Minor > Attachments: compilerWarningsBuild.png, compilerWarningsIcon.png, > compilerWarningsList.png, compilerWarningsTrend.png > > > Hi, > Would it be possible to configure the label "Compiler Warnings". > I am using the Warnings plugin to show FlawFinder issues. > Seeing text like "FlawFinder Warnings" or maybe "FlawFinder Issues" would > enhance my display. > Can the parser name (e.g. FlawFinder in my case) be used instead of the text > "Compiler" ? > Or, maybe the ability to change the label "Compiler Warnings" to something > else ? > I can see the text "Compiler Warnings" in a number of places which I've > attached screenshots of. The "Compiler Warnings" text may also appear > elsewhere. > Great plugin by the way ! > Many thanks, > Nigel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160230#comment-160230 ] allenservedio commented on JENKINS-12994: - To work around this, I have removed the quiet period from all of my jobs (running on 1.455 now). This will mean we will get out of order builds sometimes as it will not necessarily see changes from dependent repos - but we can live with that for a bit until this is fixed. > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12216) Rake/Ruby build step is not available in actions for other plugins
[
https://issues.jenkins-ci.org/browse/JENKINS-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dieter De Meyer updated JENKINS-12216:
--
Summary: Rake/Ruby build step is not available in actions for other
plugins (was: Rake build step is not available in actions from promoted_build
plugin)
Environment:
Jenkins 1.420 & 1.444
Rake plugin 1.7.7
Promoted build plugin 2.4
Conditional buildstep plugin 0.3
was:
Jenkins 1.420 & 1.444
Rake plugin 1.7.7
Promoted build plugin 2.4
Component/s: ruby
> Rake/Ruby build step is not available in actions for other plugins
> --
>
> Key: JENKINS-12216
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12216
> Project: Jenkins
> Issue Type: Bug
> Components: rake, ruby
>Affects Versions: current
> Environment: Jenkins 1.420 & 1.444
> Rake plugin 1.7.7
> Promoted build plugin 2.4
> Conditional buildstep plugin 0.3
>Reporter: Kristof Willaert
>Assignee: Dieter De Meyer
>Priority: Minor
>
> With the Rake plugin installed, a rake build step appears in the list of
> build steps. However, when also using the promoted builds plugin, the list of
> actions to be executed with a promoted build does not contain the rake build
> step.
> Upon investigation, the list of possible actions in the promoted builds
> plugin gets compiled using the following condition:
> {code}
> BuildStepDescriptor bsd = (BuildStepDescriptor) d;
> if(bsd.isApplicable(PromotionProcess.class))
> list.add(d);
> {code}
> (in
> promoted-builds-plugin/src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java)
> I guess the reason why the Rake builder does not appear in the list of
> actions, is because the RakeDescriptor class
> extends the Descriptor class instead of the
> BuildStepDescriptor class:
> {code}
> public static final class RakeDescriptor extends Descriptor {
> {code}
> (in rake-plugin/src/main/java/hudson/plugins/rake/Rake.java)
> My guess is that adding an
> {code}
> import hudson.tasks.BuildStepDescriptor;
> {code}
> and changing the RakeDescriptor class to:
> {code}
> public static final class RakeDescriptor extends BuildStepDescriptor
> {
> {code}
> might fix this.
> I have to say I am a complete Java newbie, and the Jenkins code is unknown to
> me, so
> I might be way off.
--
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-12063) Automatically update graphs when job finishes
[ https://issues.jenkins-ci.org/browse/JENKINS-12063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner updated JENKINS-12063: -- Assignee: (was: Ulli Hafner) Unassigning, this should be done in core. > Automatically update graphs when job finishes > - > > Key: JENKINS-12063 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12063 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, core >Affects Versions: current >Reporter: Greg Moncreaff >Priority: Minor > > You are on a job page, the job is in progress, regardless of whether there is > compiler warnings graph (2+ jobs run before) or no graph (only one job run > before), when the job finishes, the build status updates but not the graph. > Trend graphs are represented by static HTML in the moment. They will be > updated only if the page is refreshed (see refresh interval). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160227#comment-160227 ] Chris Nogradi commented on JENKINS-12994: - I tried upgrading to 1.452 and 1.455 and both behave as described above with all jobs remaining in 'Waiting for next executor' state with all nodes free. Downgrading to 1.451 restores functionality. > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9621) Restart after plugin installation shuts Tomcat down
[ https://issues.jenkins-ci.org/browse/JENKINS-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160226#comment-160226 ] Uwe Stuehler commented on JENKINS-9621: --- Just for the record: We have also avoided the issue altogether by switching from Tomcat to Winstone. I am not sure however if it was something in our Tomcat/Tanuki configuration or something else. > Restart after plugin installation shuts Tomcat down > --- > > Key: JENKINS-9621 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9621 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Debian 6, Tomcat 7.0.11, Jenkins 1.410 >Reporter: Manuel Doninger >Priority: Critical > > The restart after a plugin installation via the "Restart when no jobs are > running" button in the Plugin Manager shuts down the complete Tomcat > instance, but the instance isn't coming up, i have to start it manually. > I think that Jenkins should not shut down, if it is deployed into a container > (i don't know if it's possible to determine), rather than let the > administrator use the container facilities to restart an application. -- 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-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[ https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160225#comment-160225 ] Richard Mortimer commented on JENKINS-12037: @George Panayotov thanks for the data. This does indeed look like similar symptoms to JENKINS-12037. Thank you for taking a look using WireShark that might be a big clue as to what is going on. Looking at the source in [FullDuplexHttpChannel.java|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/FullDuplexHttpChannel.java] that sets isRestricted based on user authentication so this could give a clue as to why it might occur for some and not others. That said if you still have the Wireshark output around can you take a look to see if you can answer the following: * Does the "is prohibited because the channel is restricted" message get repeated or does it just occur once at the start of the CLI session? * Do you see any other activity on either of the two http streams (upstream and downstream) during the 60 seconds after the initial activity? Richard > CLI - I/O error in channel Chunked connection/Unexpected termination of the > channel - still occurring in Jenkins 1.449 > -- > > Key: JENKINS-12037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12037 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: * Running on SLES9 Linux server with 4 CPUs and plenty > of diskspace. > * Tomcat 7.0.22 > * JDK 1.6.0_14 > * Only ONE Master configuration - no slaves are configured > * 3 Executors - (one less than the max number of CPUs) >Reporter: mark streit >Priority: Critical > Attachments: Tomcat7_Jenkins1449_logs.zip > > > We reported an issue some time back that was also listed as fixed in Jenkins > 1.441: > Log: > [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when > using jenkins-cli.jar > Perhaps another bug should NOT be submitted so I have added the following > comments below the line to the original defect 11130 comments section in case > it can be reviewed/re-opened. > We did NOT try to make any adjustments to the Tomcat configuration: > Tomcat Connector connectionUploadTimeout > but we are also now seeing the same problem with Winstone when at this same > 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR > at 1.441 running in Winstone) and that is serving asthe current workaround. > > We have downloaded and installed the LATEST 1.441 release that lists the fix > for this problem. Currently we were running 1.438 on Winstone only (since > with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, > it worked OK so that was our workaround - while running 1.438). > Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH > Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR > file in place running on Winstone, and reverted the CLI jar file back to the > 1.438 version for now and that appears to work again with Winstone. > Checked Manifest of CLI jar downloaded with the 1.441 WAR installation: > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: kohsuke > Build-Jdk: 1.6.0_26 > Main-Class: hudson.cli.CLI > Jenkins-CLI-Version: 1.441 > Under Tomcat 7, we get this stacktrace: > Started by command line > [workspace] $ /bin/bash -xe > /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh > + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar > -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p > SVN_PATH=trunk > Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run > SEVERE: I/O error in channel Chunked connection to > http://11.22.33.44:8082/jenkins/cli > java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > Exception in thread "main" hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(
[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[ https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160224#comment-160224 ] Richard Mortimer commented on JENKINS-12037: @Miguel Almeida thanks for the information. At the moment that seems sufficiently different to the situation/symptoms reported in this JIRA that I think it would be best if you could report that as a separate JIRA to stop confusion over symptoms. It may turn out to be related once the root cause is known as @brianharris points out. > CLI - I/O error in channel Chunked connection/Unexpected termination of the > channel - still occurring in Jenkins 1.449 > -- > > Key: JENKINS-12037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12037 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: * Running on SLES9 Linux server with 4 CPUs and plenty > of diskspace. > * Tomcat 7.0.22 > * JDK 1.6.0_14 > * Only ONE Master configuration - no slaves are configured > * 3 Executors - (one less than the max number of CPUs) >Reporter: mark streit >Priority: Critical > Attachments: Tomcat7_Jenkins1449_logs.zip > > > We reported an issue some time back that was also listed as fixed in Jenkins > 1.441: > Log: > [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when > using jenkins-cli.jar > Perhaps another bug should NOT be submitted so I have added the following > comments below the line to the original defect 11130 comments section in case > it can be reviewed/re-opened. > We did NOT try to make any adjustments to the Tomcat configuration: > Tomcat Connector connectionUploadTimeout > but we are also now seeing the same problem with Winstone when at this same > 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR > at 1.441 running in Winstone) and that is serving asthe current workaround. > > We have downloaded and installed the LATEST 1.441 release that lists the fix > for this problem. Currently we were running 1.438 on Winstone only (since > with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, > it worked OK so that was our workaround - while running 1.438). > Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH > Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR > file in place running on Winstone, and reverted the CLI jar file back to the > 1.438 version for now and that appears to work again with Winstone. > Checked Manifest of CLI jar downloaded with the 1.441 WAR installation: > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: kohsuke > Build-Jdk: 1.6.0_26 > Main-Class: hudson.cli.CLI > Jenkins-CLI-Version: 1.441 > Under Tomcat 7, we get this stacktrace: > Started by command line > [workspace] $ /bin/bash -xe > /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh > + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar > -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p > SVN_PATH=trunk > Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run > SEVERE: I/O error in channel Chunked connection to > http://11.22.33.44:8082/jenkins/cli > java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > Exception in thread "main" hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) > at $Proxy2.main(Unknown Source) > at hudson.cli.CLI.execute(CLI.java:200) > at hudson.cli.CLI._main(CLI.java:330) > at hudson.cli.CLI.main(CLI.java:245) > Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel > at hudson.remoting.Request.abort(Request.java:273) > at hudson.remoting.Channel.terminate(Channel.java:732) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1139) > Caused by: java.io.IOException: Unexpected termination of the channel > at hudson.r
[JIRA] (JENKINS-13066) unable to update CVS plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160223#comment-160223 ] Michael Clarke commented on JENKINS-13066: -- Can you confirm if the resolution steps in the description of JENKINS-1454 do anything to fix your issue, and also check if there's any errors in the logs from Jenkins starting up? > unable to update CVS plugin > --- > > Key: JENKINS-13066 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13066 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: Jenkins: 1.454 > Current CVS version:1.6 > Available version:2.0 >Reporter: Mingjiang Shi >Priority: Blocker > > Unable to install the new plugin. Once I tried to install it as other > plugins and resart Jenkins, cvs plugin version 1.6 is displayed and the > button revert to 1.6 is also displayed. -- 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-12216) Rake build step is not available in actions from promoted_build plugin
[
https://issues.jenkins-ci.org/browse/JENKINS-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JENKINS-12216 stopped by Dieter De Meyer.
> Rake build step is not available in actions from promoted_build plugin
> --
>
> Key: JENKINS-12216
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12216
> Project: Jenkins
> Issue Type: Bug
> Components: rake
>Affects Versions: current
> Environment: Jenkins 1.420 & 1.444
> Rake plugin 1.7.7
> Promoted build plugin 2.4
>Reporter: Kristof Willaert
>Assignee: Dieter De Meyer
>Priority: Minor
>
> With the Rake plugin installed, a rake build step appears in the list of
> build steps. However, when also using the promoted builds plugin, the list of
> actions to be executed with a promoted build does not contain the rake build
> step.
> Upon investigation, the list of possible actions in the promoted builds
> plugin gets compiled using the following condition:
> {code}
> BuildStepDescriptor bsd = (BuildStepDescriptor) d;
> if(bsd.isApplicable(PromotionProcess.class))
> list.add(d);
> {code}
> (in
> promoted-builds-plugin/src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java)
> I guess the reason why the Rake builder does not appear in the list of
> actions, is because the RakeDescriptor class
> extends the Descriptor class instead of the
> BuildStepDescriptor class:
> {code}
> public static final class RakeDescriptor extends Descriptor {
> {code}
> (in rake-plugin/src/main/java/hudson/plugins/rake/Rake.java)
> My guess is that adding an
> {code}
> import hudson.tasks.BuildStepDescriptor;
> {code}
> and changing the RakeDescriptor class to:
> {code}
> public static final class RakeDescriptor extends BuildStepDescriptor
> {
> {code}
> might fix this.
> I have to say I am a complete Java newbie, and the Jenkins code is unknown to
> me, so
> I might be way off.
--
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-12216) Rake build step is not available in actions from promoted_build plugin
[
https://issues.jenkins-ci.org/browse/JENKINS-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JENKINS-12216 started by Dieter De Meyer.
> Rake build step is not available in actions from promoted_build plugin
> --
>
> Key: JENKINS-12216
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12216
> Project: Jenkins
> Issue Type: Bug
> Components: rake
>Affects Versions: current
> Environment: Jenkins 1.420 & 1.444
> Rake plugin 1.7.7
> Promoted build plugin 2.4
>Reporter: Kristof Willaert
>Assignee: Dieter De Meyer
>Priority: Minor
>
> With the Rake plugin installed, a rake build step appears in the list of
> build steps. However, when also using the promoted builds plugin, the list of
> actions to be executed with a promoted build does not contain the rake build
> step.
> Upon investigation, the list of possible actions in the promoted builds
> plugin gets compiled using the following condition:
> {code}
> BuildStepDescriptor bsd = (BuildStepDescriptor) d;
> if(bsd.isApplicable(PromotionProcess.class))
> list.add(d);
> {code}
> (in
> promoted-builds-plugin/src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java)
> I guess the reason why the Rake builder does not appear in the list of
> actions, is because the RakeDescriptor class
> extends the Descriptor class instead of the
> BuildStepDescriptor class:
> {code}
> public static final class RakeDescriptor extends Descriptor {
> {code}
> (in rake-plugin/src/main/java/hudson/plugins/rake/Rake.java)
> My guess is that adding an
> {code}
> import hudson.tasks.BuildStepDescriptor;
> {code}
> and changing the RakeDescriptor class to:
> {code}
> public static final class RakeDescriptor extends BuildStepDescriptor
> {
> {code}
> might fix this.
> I have to say I am a complete Java newbie, and the Jenkins code is unknown to
> me, so
> I might be way off.
--
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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160222#comment-160222 ] vjuranek commented on JENKINS-12962: I've already released it. Not sure precisely how long it takes to be available in update center, but it should be there in a few hours. > Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin > --- > > Key: JENKINS-12962 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 > Project: Jenkins > Issue Type: Bug > Components: ws-cleanup >Affects Versions: current > Environment: Jenkins 1.452, Win7 >Reporter: Thomas Fields >Assignee: vjuranek > > Hi there, > The Workspace Cleanup Plugin does not play nicely with the Copy To Slave > plugin. Here's a snippet from my console output for my build: > 14:33:23 Deleting project workspace... done > 14:33:23 > 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, > Engine/Lib/**/*.a', excluding nothing, from > 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on > 'hudson.slaves.DumbSlave@720397f7' to > 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. > Note how the workspace is deleted before the copy step begins. Can this be > fixed please? I assume deleting a workspace is something you'd always want to > do last. > I'd be happy to test any fixes. > Regards, > Tom. -- 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-12216) Rake build step is not available in actions from promoted_build plugin
[
https://issues.jenkins-ci.org/browse/JENKINS-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160221#comment-160221
]
didi357 commented on JENKINS-12216:
---
I have fixed this issue and sent a pull request in the rake-plugin project on
Github.
Pull request can be found here: https://github.com/jenkinsci/rake-plugin/pull/9
Regards.
> Rake build step is not available in actions from promoted_build plugin
> --
>
> Key: JENKINS-12216
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12216
> Project: Jenkins
> Issue Type: Bug
> Components: rake
>Affects Versions: current
> Environment: Jenkins 1.420 & 1.444
> Rake plugin 1.7.7
> Promoted build plugin 2.4
>Reporter: Kristof Willaert
>Assignee: didi357
>Priority: Minor
>
> With the Rake plugin installed, a rake build step appears in the list of
> build steps. However, when also using the promoted builds plugin, the list of
> actions to be executed with a promoted build does not contain the rake build
> step.
> Upon investigation, the list of possible actions in the promoted builds
> plugin gets compiled using the following condition:
> {code}
> BuildStepDescriptor bsd = (BuildStepDescriptor) d;
> if(bsd.isApplicable(PromotionProcess.class))
> list.add(d);
> {code}
> (in
> promoted-builds-plugin/src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java)
> I guess the reason why the Rake builder does not appear in the list of
> actions, is because the RakeDescriptor class
> extends the Descriptor class instead of the
> BuildStepDescriptor class:
> {code}
> public static final class RakeDescriptor extends Descriptor {
> {code}
> (in rake-plugin/src/main/java/hudson/plugins/rake/Rake.java)
> My guess is that adding an
> {code}
> import hudson.tasks.BuildStepDescriptor;
> {code}
> and changing the RakeDescriptor class to:
> {code}
> public static final class RakeDescriptor extends BuildStepDescriptor
> {
> {code}
> might fix this.
> I have to say I am a complete Java newbie, and the Jenkins code is unknown to
> me, so
> I might be way off.
--
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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160220#comment-160220 ] Thomas Fields commented on JENKINS-12962: - Thanks for fixing this issue. Do you know when ws-cleanup 0.8 will be available? If it's going to be a while can I get a preview copy please? Regards, Tom. > Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin > --- > > Key: JENKINS-12962 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 > Project: Jenkins > Issue Type: Bug > Components: ws-cleanup >Affects Versions: current > Environment: Jenkins 1.452, Win7 >Reporter: Thomas Fields >Assignee: vjuranek > > Hi there, > The Workspace Cleanup Plugin does not play nicely with the Copy To Slave > plugin. Here's a snippet from my console output for my build: > 14:33:23 Deleting project workspace... done > 14:33:23 > 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, > Engine/Lib/**/*.a', excluding nothing, from > 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on > 'hudson.slaves.DumbSlave@720397f7' to > 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. > Note how the workspace is deleted before the copy step begins. Can this be > fixed please? I assume deleting a workspace is something you'd always want to > do last. > I'd be happy to test any fixes. > Regards, > Tom. -- 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-12216) Rake build step is not available in actions from promoted_build plugin
[
https://issues.jenkins-ci.org/browse/JENKINS-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
didi357 reassigned JENKINS-12216:
-
Assignee: didi357 (was: david_calavera)
> Rake build step is not available in actions from promoted_build plugin
> --
>
> Key: JENKINS-12216
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12216
> Project: Jenkins
> Issue Type: Bug
> Components: rake
>Affects Versions: current
> Environment: Jenkins 1.420 & 1.444
> Rake plugin 1.7.7
> Promoted build plugin 2.4
>Reporter: Kristof Willaert
>Assignee: didi357
>Priority: Minor
>
> With the Rake plugin installed, a rake build step appears in the list of
> build steps. However, when also using the promoted builds plugin, the list of
> actions to be executed with a promoted build does not contain the rake build
> step.
> Upon investigation, the list of possible actions in the promoted builds
> plugin gets compiled using the following condition:
> {code}
> BuildStepDescriptor bsd = (BuildStepDescriptor) d;
> if(bsd.isApplicable(PromotionProcess.class))
> list.add(d);
> {code}
> (in
> promoted-builds-plugin/src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java)
> I guess the reason why the Rake builder does not appear in the list of
> actions, is because the RakeDescriptor class
> extends the Descriptor class instead of the
> BuildStepDescriptor class:
> {code}
> public static final class RakeDescriptor extends Descriptor {
> {code}
> (in rake-plugin/src/main/java/hudson/plugins/rake/Rake.java)
> My guess is that adding an
> {code}
> import hudson.tasks.BuildStepDescriptor;
> {code}
> and changing the RakeDescriptor class to:
> {code}
> public static final class RakeDescriptor extends BuildStepDescriptor
> {
> {code}
> might fix this.
> I have to say I am a complete Java newbie, and the Jenkins code is unknown to
> me, so
> I might be way off.
--
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-12216) Rake build step is not available in actions from promoted_build plugin
[
https://issues.jenkins-ci.org/browse/JENKINS-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JENKINS-12216 started by didi357.
> Rake build step is not available in actions from promoted_build plugin
> --
>
> Key: JENKINS-12216
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12216
> Project: Jenkins
> Issue Type: Bug
> Components: rake
>Affects Versions: current
> Environment: Jenkins 1.420 & 1.444
> Rake plugin 1.7.7
> Promoted build plugin 2.4
>Reporter: Kristof Willaert
>Assignee: didi357
>Priority: Minor
>
> With the Rake plugin installed, a rake build step appears in the list of
> build steps. However, when also using the promoted builds plugin, the list of
> actions to be executed with a promoted build does not contain the rake build
> step.
> Upon investigation, the list of possible actions in the promoted builds
> plugin gets compiled using the following condition:
> {code}
> BuildStepDescriptor bsd = (BuildStepDescriptor) d;
> if(bsd.isApplicable(PromotionProcess.class))
> list.add(d);
> {code}
> (in
> promoted-builds-plugin/src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java)
> I guess the reason why the Rake builder does not appear in the list of
> actions, is because the RakeDescriptor class
> extends the Descriptor class instead of the
> BuildStepDescriptor class:
> {code}
> public static final class RakeDescriptor extends Descriptor {
> {code}
> (in rake-plugin/src/main/java/hudson/plugins/rake/Rake.java)
> My guess is that adding an
> {code}
> import hudson.tasks.BuildStepDescriptor;
> {code}
> and changing the RakeDescriptor class to:
> {code}
> public static final class RakeDescriptor extends BuildStepDescriptor
> {
> {code}
> might fix this.
> I have to say I am a complete Java newbie, and the Jenkins code is unknown to
> me, so
> I might be way off.
--
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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160218#comment-160218 ] vjuranek commented on JENKINS-12962: well, IMHO it's a bug in copy-to-slave plugin (unexpected behavior), but it's more easy to fix it directly here as probably this issue is present in more plugins :-( > Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin > --- > > Key: JENKINS-12962 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 > Project: Jenkins > Issue Type: Bug > Components: ws-cleanup >Affects Versions: current > Environment: Jenkins 1.452, Win7 >Reporter: Thomas Fields >Assignee: vjuranek > > Hi there, > The Workspace Cleanup Plugin does not play nicely with the Copy To Slave > plugin. Here's a snippet from my console output for my build: > 14:33:23 Deleting project workspace... done > 14:33:23 > 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, > Engine/Lib/**/*.a', excluding nothing, from > 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on > 'hudson.slaves.DumbSlave@720397f7' to > 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. > Note how the workspace is deleted before the copy step begins. Can this be > fixed please? I assume deleting a workspace is something you'd always want to > do last. > I'd be happy to test any fixes. > Regards, > Tom. -- 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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160219#comment-160219 ] vjuranek commented on JENKINS-12962: should be fixed in ws-cleanup 0.8 > Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin > --- > > Key: JENKINS-12962 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 > Project: Jenkins > Issue Type: Bug > Components: ws-cleanup >Affects Versions: current > Environment: Jenkins 1.452, Win7 >Reporter: Thomas Fields >Assignee: vjuranek > > Hi there, > The Workspace Cleanup Plugin does not play nicely with the Copy To Slave > plugin. Here's a snippet from my console output for my build: > 14:33:23 Deleting project workspace... done > 14:33:23 > 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, > Engine/Lib/**/*.a', excluding nothing, from > 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on > 'hudson.slaves.DumbSlave@720397f7' to > 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. > Note how the workspace is deleted before the copy step begins. Can this be > fixed please? I assume deleting a workspace is something you'd always want to > do last. > I'd be happy to test any fixes. > Regards, > Tom. -- 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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12962. Resolution: Fixed > Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin > --- > > Key: JENKINS-12962 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 > Project: Jenkins > Issue Type: Bug > Components: ws-cleanup >Affects Versions: current > Environment: Jenkins 1.452, Win7 >Reporter: Thomas Fields >Assignee: vjuranek > > Hi there, > The Workspace Cleanup Plugin does not play nicely with the Copy To Slave > plugin. Here's a snippet from my console output for my build: > 14:33:23 Deleting project workspace... done > 14:33:23 > 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, > Engine/Lib/**/*.a', excluding nothing, from > 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on > 'hudson.slaves.DumbSlave@720397f7' to > 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. > Note how the workspace is deleted before the copy step begins. Can this be > fixed please? I assume deleting a workspace is something you'd always want to > do last. > I'd be happy to test any fixes. > Regards, > Tom. -- 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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160217#comment-160217 ] SCM/JIRA link daemon commented on JENKINS-12962: Code changed in jenkins User: Vojtech Juranek Path: src/main/java/hudson/plugins/ws_cleanup/PreBuildCleanup.java src/main/java/hudson/plugins/ws_cleanup/WsCleanup.java http://jenkins-ci.org/commit/ws-cleanup-plugin/7eb7c37e263c833969542a6e1337ecfebd41ff46 Log: [FIXED JENKINS-12962] Change the behavior of post build detele to run after build marked as finished as some plugins (like copy-to-slave) also run in this phase and fail because of deleted workspace. > Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin > --- > > Key: JENKINS-12962 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 > Project: Jenkins > Issue Type: Bug > Components: ws-cleanup >Affects Versions: current > Environment: Jenkins 1.452, Win7 >Reporter: Thomas Fields >Assignee: vjuranek > > Hi there, > The Workspace Cleanup Plugin does not play nicely with the Copy To Slave > plugin. Here's a snippet from my console output for my build: > 14:33:23 Deleting project workspace... done > 14:33:23 > 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, > Engine/Lib/**/*.a', excluding nothing, from > 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on > 'hudson.slaves.DumbSlave@720397f7' to > 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. > Note how the workspace is deleted before the copy step begins. Can this be > fixed please? I assume deleting a workspace is something you'd always want to > do last. > I'd be happy to test any fixes. > Regards, > Tom. -- 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-12330) Occasionally,collecting findbugs analysis files will take very long time, event two more hours.
[ https://issues.jenkins-ci.org/browse/JENKINS-12330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160216#comment-160216 ] Ulli Hafner commented on JENKINS-12330: --- Ok, I see. Thanks for the trace. The plug-in copies all the files from your slave to the master node. If there are a lot of files then this process can be slow indeed. How is your master and slave connected? > Occasionally,collecting findbugs analysis files will take very long time, > event two more hours. > --- > > Key: JENKINS-12330 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12330 > Project: Jenkins > Issue Type: Bug > Components: findbugs >Affects Versions: current > Environment: ubuntu 10.04 LTS >Reporter: roger four >Assignee: Ulli Hafner > Labels: plugin > > Occasionally,I found findbugs will take very long time to analysis files.Some > time it will take two more hours. > Just stop at: > [FINDBUGS] Collecting findbugs analysis files... > And I had to kill the process. > It bothers me very much.Pls help me. > 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-12972) Add option to run 'git bisect' to find which commit added new bugs
[ https://issues.jenkins-ci.org/browse/JENKINS-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner updated JENKINS-12972: -- Assignee: (was: Ulli Hafner) Unassigning since this needs some work in core first. > Add option to run 'git bisect' to find which commit added new bugs > --- > > Key: JENKINS-12972 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12972 > Project: Jenkins > Issue Type: New Feature > Components: analysis-core, core, findbugs, git >Reporter: Eyal Edri >Priority: Minor > > Today, when you run find-bugs plug-in triggered by a git commit, you can't > know exactly which commit added those bugs. > It becomes especially difficult to know when a high volume of commits is > pushed at once. > find-bugs plug-in could have a new option to tick in the 'advanced section', > which will do a 'git bisect' on the git commits that caused a new bug and > display/email to commiter who did it. > that would simply and automate the process of finding who wrote the bug. -- 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-13056) Obtain reference build from SCM/Trigger
[ https://issues.jenkins-ci.org/browse/JENKINS-13056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner updated JENKINS-13056: -- Summary: Obtain reference build from SCM/Trigger (was: Warnigs Reference Build from SCM/Trigger) Component/s: analysis-core core I think that feature is something that should be first added to core (SCM) as an extension point. E.g. in general the build stable results (test results, analysis results, etc.) should use that extension point to determine a reference build. Or is this only meaningful for static analysis? When this extension point is provided, the static analysis plug-in can use that extension point to provide that behavior. Can you please add some build sequences or examples to describe in more detail your requirements? Currently, in the warnings plug-in a reference build is the last build with results below a threshold. Should this also be done in your use case? > Obtain reference build from SCM/Trigger > --- > > Key: JENKINS-13056 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13056 > Project: Jenkins > Issue Type: Bug > Components: analysis-core, core, warnings >Reporter: Roland Schulz >Assignee: Ulli Hafner > > It would be great if the SCM would be queried for the reference build. If the > builds are not in order (e.g. because the build are triggered by code review > (e.g. Gerrit)), it doesn't make sense to use the last build as reference. The > SCM (e.g. Git) or the Trigger (e.g. Gerrit) would know the previous commit > which should be used as reference. -- 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-13068) Failed tests are not shown on main page in maven jobs
Ulli Hafner created JENKINS-13068: - Summary: Failed tests are not shown on main page in maven jobs Key: JENKINS-13068 URL: https://issues.jenkins-ci.org/browse/JENKINS-13068 Project: Jenkins Issue Type: Improvement Components: core, maven Environment: Jenkins 1.424.6 Reporter: Ulli Hafner Priority: Minor Attachments: screenshot_197.png We have a multi-module maven project using maven job type in Jenkins. When one of our tests fails then the failing test is not directly shown on the main page of the test results (job/[name]/[number]/testReport/). Jenkins should: - show the failed tests on the top of the page (as this is done for freestyle jobs) - show the build result icon on each of the shown modules See the attached screenshot for the current results. -- 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-13060) Can not access by --prefix value even if --prefix is set
[ https://issues.jenkins-ci.org/browse/JENKINS-13060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160213#comment-160213 ] Kiril Mitov commented on JENKINS-13060: --- A discussion on this issues in stackoverflow still does not lead to anything - http://stackoverflow.com/questions/9685782/can-not-access-jenkins-by-prefix-value-even-if-prefix-is-set > Can not access by --prefix value even if --prefix is set > > > Key: JENKINS-13060 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13060 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Linux robopar12227 2.6.35-22-server #35-Ubuntu SMP Sat > Oct 16 22:02:33 UTC 2010 x86_64 GNU/Linux > java version "1.6.0_20" > OpenJDK Runtime Environment (IcedTea6 1.9.13) (6b20-1.9.13-0ubuntu1~10.10.1) > OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) > Jenkins ver. 1.447 >Reporter: Kiril Mitov > Labels: jenkins > > I have set the JENKINS_ARGS using /etc/default/jenkins and start jenkins as a > daemon with the www-data user. > The system info page shows that --prefix=/jenkins is set > HOME /var/www > HUDSON_HOME /var/jenkins > JENKINS_ARGS --prefix=/jenkins > But still jenkins is only accessible via http://ip:port/ and not > http://ip:port/jenkin. > I have also setting the Jenkins URL on the configuration page, but without > success. -- 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-10899) Add the ability to show/edit from a job's configuration UI, a properties file containing env vars to be set by envinject
[ https://issues.jenkins-ci.org/browse/JENKINS-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160212#comment-160212 ] bogdaniosif commented on JENKINS-10899: --- @gbois can you please comment on this feature request? I would like to make sure that it's clearly formulated since I see that it's the single remaining open issue for envinject. I'll state again the need, as succinctly as I can: - Define in a single .properties file, env vars to be set by envinject during normal job execution for multiple jobs. Assume we need to store this file on the build server because it stores env vars needed before source control is accessed. - PROBLEM: The only way for a build engineer inspecting these jobs' configurations in Jenkins' web UI, to also inspect the content of the .properties file is to use an additional channel; e.g. connect remotely to Jenkins' host and list / edit that .properties file. It would be of great help to at least be able to see the content of the .properties file via Jenkins' web UI, in read only mode. It would be fantastic to be able to edit the file via the Jenkins UI. > Add the ability to show/edit from a job's configuration UI, a properties file > containing env vars to be set by envinject > > > Key: JENKINS-10899 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10899 > Project: Jenkins > Issue Type: New Feature > Components: envinject >Reporter: bogdaniosif >Assignee: gbois > > When env vars to be set by envinject are stored in a properties file, the > following problem arises from a job's admin perspective: How is the file > viewed/edited? The problem is bigger when the file is not coming from SCM, > instead it just sits permanently in some location on the build server, e.g. > in the same folder as the job's config.xml > _*Feature Request:*_ Add to envinject the ability to show/edit in the job's > configuration UI the content of a file containing env vars to be set. If it's > possible, show/edit the content inline in the configuration page. -- 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-13067) Baselines are created with -identical switch: Don't do that
[ https://issues.jenkins-ci.org/browse/JENKINS-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Wolfgang reassigned JENKINS-13067: Assignee: Christian Wolfgang > Baselines are created with -identical switch: Don't do that > --- > > Key: JENKINS-13067 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13067 > Project: Jenkins > Issue Type: Improvement > Components: clearcase-ucm >Affects Versions: current > Environment: N/A >Reporter: Lars Kruse >Assignee: Christian Wolfgang > > The check box in "make baseline" creates a new baseline on the stream when > running in child or sibling mode and build is successful. But the baseline is > created with the -identical switch (and potentially also -all?) which causes > baselines to be created - even on non-modifiable components. > Please loose the -identical switch (and -all if it's used). > This feature is requested and sponsored by Grundfos -- 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-13067) Baselines are created with -identical switch: Don't do that
[ https://issues.jenkins-ci.org/browse/JENKINS-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Wolfgang resolved JENKINS-13067. -- Resolution: Fixed > Baselines are created with -identical switch: Don't do that > --- > > Key: JENKINS-13067 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13067 > Project: Jenkins > Issue Type: Improvement > Components: clearcase-ucm >Affects Versions: current > Environment: N/A >Reporter: Lars Kruse >Assignee: Christian Wolfgang > > The check box in "make baseline" creates a new baseline on the stream when > running in child or sibling mode and build is successful. But the baseline is > created with the -identical switch (and potentially also -all?) which causes > baselines to be created - even on non-modifiable components. > Please loose the -identical switch (and -all if it's used). > This feature is requested and sponsored by Grundfos -- 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
