[JIRA] (JENKINS-12891) Use a temporary name for the uploading files
Artem V. Navrotskiy created JENKINS-12891:
-
Summary: Use a temporary name for the uploading files
Key: JENKINS-12891
URL: https://issues.jenkins-ci.org/browse/JENKINS-12891
Project: Jenkins
Issue Type: Improvement
Components: publish-over-ssh
Affects Versions: current
Reporter: Artem V. Navrotskiy
Assignee: bap
Now when downloading large files for a long time at the destination may not be
a complete file. This can lead to various problems.
To avoid this problem you need to load it under a temporary name and then
rename the.
For example:
{code}
sftp put bigfile.bin bigfile.bin~tmp123
sftp rename bigfile.bin~tmp123 bigfile.bin
{code}
Now you need to do:
- Script to rename a file in the working directory;
- Upload renamed files by ssh;
- Using Exec command to change cuurent directory to upload directory
(JENKINS-12890) and rename files back.
This workaround looks like ugly :(
--
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-12226) Triggering a build with Current build parameters fails when the current build parameters includes a node name
[ https://issues.jenkins-ci.org/browse/JENKINS-12226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159504#comment-159504 ] domi commented on JENKINS-12226: to be more precise, this occurs if the target job does not have any parameters set. Triggering a build with Current build parameters fails when the current build parameters includes a node name --- Key: JENKINS-12226 URL: https://issues.jenkins-ci.org/browse/JENKINS-12226 Project: Jenkins Issue Type: Bug Components: nodelabelparameter, parameterized-trigger Environment: Jenkins 1.436, NodeLabel 1.1.1, Parameterized Trigger 2.11 Reporter: Michael Conlon Assignee: domi In the process of discussing JENKINS-12155, I realized there was an underlying problem with the way these plugins interact. Triggering a build of a job with Current build parameters doesn't work if there's a node parameter involved. It creates this error: Building remotely on [node] FATAL: null java.lang.NullPointerException at org.jvnet.jenkins.plugins.nodelabelparameter.NodeParameterValue.createBuildWrapper(NodeParameterValue.java:82) at hudson.model.ParametersAction.createBuildWrappers(ParametersAction.java:74) at hudson.model.Build$RunnerImpl.doRun(Build.java:130) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:460) 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) I discovered the only way to pass a node parameter to another job is to trigger it individually with a NodeLabel parameter. This breaks the Current build parameters functionality. WORKAROUND: To achieve the same effect as Current build parameters, I have to choose a NodeLabel parameter with node=$NODE_NAME, and copy all of my previously defined parameters into Predefined parameters. This is a minor pain. -- 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-12880) Enable the selection of the brower/version/operating system for single Jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159503#comment-159503 ] SCM/JIRA link daemon commented on JENKINS-12880: Code changed in jenkins User: Ross Rowe Path: src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandBuildWrapper.java src/main/resources/hudson/plugins/sauce_ondemand/SauceOnDemandBuildWrapper/config.jelly http://jenkins-ci.org/commit/sauce-ondemand-plugin/a3949e2a94187feafca29f2b15ad32d205ead7ea Log: JENKINS-12880 Changed the browser selection to a multi select list Enable the selection of the brower/version/operating system for single Jobs --- Key: JENKINS-12880 URL: https://issues.jenkins-ci.org/browse/JENKINS-12880 Project: Jenkins Issue Type: Improvement Components: sauce-ondemand Reporter: Ross Rowe Assignee: Ross Rowe Currently, the only way to select the browser/version/operating system to be used for Selenium tests run under Sauce OnDemand is via the Multi-config job. The plugin should be updated to allow for the selection of the browser/version/operating system combination that will be used for single Jobs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12226) Triggering a build with Current build parameters fails when the current build parameters includes a node name
[ https://issues.jenkins-ci.org/browse/JENKINS-12226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12226. Resolution: Fixed Triggering a build with Current build parameters fails when the current build parameters includes a node name --- Key: JENKINS-12226 URL: https://issues.jenkins-ci.org/browse/JENKINS-12226 Project: Jenkins Issue Type: Bug Components: nodelabelparameter, parameterized-trigger Environment: Jenkins 1.436, NodeLabel 1.1.1, Parameterized Trigger 2.11 Reporter: Michael Conlon Assignee: domi In the process of discussing JENKINS-12155, I realized there was an underlying problem with the way these plugins interact. Triggering a build of a job with Current build parameters doesn't work if there's a node parameter involved. It creates this error: Building remotely on [node] FATAL: null java.lang.NullPointerException at org.jvnet.jenkins.plugins.nodelabelparameter.NodeParameterValue.createBuildWrapper(NodeParameterValue.java:82) at hudson.model.ParametersAction.createBuildWrappers(ParametersAction.java:74) at hudson.model.Build$RunnerImpl.doRun(Build.java:130) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:460) 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) I discovered the only way to pass a node parameter to another job is to trigger it individually with a NodeLabel parameter. This breaks the Current build parameters functionality. WORKAROUND: To achieve the same effect as Current build parameters, I have to choose a NodeLabel parameter with node=$NODE_NAME, and copy all of my previously defined parameters into Predefined parameters. This is a minor pain. -- 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-8860) Views select list sorting should be case-insensitive
[ https://issues.jenkins-ci.org/browse/JENKINS-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159508#comment-159508 ] evernat commented on JENKINS-8860: -- Hi Rob, Thanks for the screenshot. I see now that I was not testing the same thing. Views select list sorting should be case-insensitive Key: JENKINS-8860 URL: https://issues.jenkins-ci.org/browse/JENKINS-8860 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: Rob Hruska Priority: Minor Attachments: screenshot-1.jpg In the views select list, the sort order is currently case-sensitive. For example, the following entries would currently be sorted: Alpha Beta Gamma aardvark gorilla Where the ideal sorting would be: aardvark Alpha Beta Gamma gorilla The list should have a natural sort order that is case insensitive. It should be noted that case-insensitive ordering is Jenkins' behavior by default when displaying tabs, so the current behavior of the select list differs from that of Jenkins. Ultimately, the sorting should match how Jenkins orders the tabs when the plugin is not installed. -- 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-12892) Add support for environment variables
Julien Eluard created JENKINS-12892: --- Summary: Add support for environment variables Key: JENKINS-12892 URL: https://issues.jenkins-ci.org/browse/JENKINS-12892 Project: Jenkins Issue Type: New Feature Components: ion-deployer Reporter: Julien Eluard Assignee: Julien Eluard iON supports per deployment environment variables override. Add support for this. -- 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-12893) Make domain field a list
Julien Eluard created JENKINS-12893: --- Summary: Make domain field a list Key: JENKINS-12893 URL: https://issues.jenkins-ci.org/browse/JENKINS-12893 Project: Jenkins Issue Type: Improvement Components: ion-deployer Reporter: Julien Eluard Assignee: Julien Eluard Domain should be a drop-down list pre-populated with all existing domains. -- 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-12879) Verion 1.27 does not work with Tool Environment plugin
[
https://issues.jenkins-ci.org/browse/JENKINS-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159509#comment-159509
]
Florian Zschocke commented on JENKINS-12879:
Thanks for the tip. I have tried to use the Shared Object plugin instead. The
problem remains because while the SO plugin does set the tool names as
environment variables which can be used in the job, they can not be used, i.e.
referenced, when injecting environment variables with EnvInject.
I have a tool naem Maven 2.2.1 which creates a env variable of the same name.
When I set the environment with EnvInject, I have something like:
MAVEN_BIN=${Maven 2.2.1}/bin
This does not work, the variable Maven 2.2.1 can not be resolved by
EnvInject. Changing the tool name to contain an underscore instead of space did
not help. Are the tool environment variables created by the SO plugin supposed
to be referencable in EnvInject configuration?
So far I have to return to SetEnv/ToolEnvironment because EnvInject cannot
replace the functionality that combi provides. What I am trying to do is get
tool paths in the PATH for jobs we run (i.e. an Ant job).
Thanks for looking into it.
Verion 1.27 does not work with Tool Environment plugin
--
Key: JENKINS-12879
URL: https://issues.jenkins-ci.org/browse/JENKINS-12879
Project: Jenkins
Issue Type: Bug
Components: envinject
Affects Versions: current
Reporter: Florian Zschocke
Assignee: gbois
Labels: plugin
We use the Tool Environment Plugin to set environment variables with path for
tools. We used the SetEnv plugin before together with the TE plugin and the
tool environment variables could be used in the SetEnv configuration. This
does not work with the EnvInject plugin, which is supposed to replace the
SetEnv plugin.
Configuration:
We have tool environment variables
MAVEN_2_2_1_HOME
JAVA_IBM_60_81_HOME
ANT_1_6_5_HOME
The SetEnv plugin set the environment for a build using these:
PROJECT_TOP=${WORKSPACE}
PROJECT_BUILD=$PROJECT_TOP/build
PROJECT_RES=$PROJECT_TOP/delivery
PROJECT_SRC=$PROJECT_TOP
JAVA_HOME=${JAVA_IBM_60_81_HOME}
PATH=${JAVA_HOME}/bin:${MAVEN_2_2_1_HOME}/bin:${ANT_1_6_5_HOME}/bin:$PATH
This would work.
Using the EnvInject plugin on a new Jenksin 1.451 installation, I was so far
not able to find any configuration which would work. The EnvInject plugin
does not see the tool environment variables, or the PATH variable. This are
the results:
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties content
BRANCH=trunk
PROJECT_TOP=${WORKSPACE}
PROJECT_BUILD=$PROJECT_TOP/build
PROJECT_RES=$PROJECT_TOP/delivery
PROJECT_SRC=$PROJECT_TOP
JAVA_HOME=${JAVA_IBM_60_81_HOME}
PATH=${JAVA_HOME}/bin:${MAVEN_2_2_1_HOME}/bin:${ANT_1_6_5_HOME}/bin:$PATH
[EnvInject] - Variables injected successfully.
[EnvInject] - Unset unresolved 'JAVA_HOME' variable.
[EnvInject] - Unset unresolved 'PATH' variable.
Setting ANT_1_6_5_HOME=/data/sourcecode/cbe-tools/ant/1.6.5
Setting MAVEN_2_2_1_HOME=/data/sourcecode/cbe-tools/maven/2.2.1
Setting JAVA_IBM_60_81_HOME=/data/build-env/java/ibm-java2-i386-6.0.8.1
or:
[EnvInject] - Executing scripts and injecting environment variables after the
SCM step.
[EnvInject] - Executing and processing the following script content:
BRANCH=trunk
PROJECT_TOP=${WORKSPACE}
PROJECT_BUILD=$PROJECT_TOP/build
PROJECT_RES=$PROJECT_TOP/delivery
PROJECT_SRC=$PROJECT_TOP
JAVA_HOME=${JAVA_IBM_60_81_HOME}
PATH=${JAVA_HOME}/bin:${MAVEN_2_2_1_HOME}/bin:${ANT_1_6_5_HOME}/bin:$PATH
[hourly] $ /bin/sh -xe /tmp/hudson6496656756456228415.sh
+ BRANCH=trunk
+ PROJECT_TOP=/data/sourcecode/domain/trunk/hourly
+ PROJECT_BUILD=/data/sourcecode/domain/trunk/hourly/build
+ PROJECT_RES=/data/sourcecode/domain/trunk/hourly/delivery
+ PROJECT_SRC=/data/sourcecode/domain/trunk/hourly
+ JAVA_HOME=
+
PATH=/bin:/bin:/bin:/data/build-env/java/ibm-java2-i386-6.0.8.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin
[EnvInject] - Script executed successfully.
Setting ANT_1_6_5_HOME=/data/sourcecode/cbe-tools/ant/1.6.5
Setting MAVEN_2_2_1_HOME=/data/sourcecode/cbe-tools/maven/2.2.1
Setting JAVA_IBM_60_81_HOME=/data/build-env/java/ibm-java2-i386-6.0.8.1
This came closest, but the PATH variable cannot be seen:
[EnvInject] - Injecting environment variables from a build step.
Setting ANT_1_6_5_HOME=/data/sourcecode/cbe-tools/ant/1.6.5
Setting MAVEN_2_2_1_HOME=/data/sourcecode/cbe-tools/maven/2.2.1
Setting JAVA_IBM_60_81_HOME=/data/build-env/java/ibm-java2-i386-6.0.8.1
[EnvInject] - Injecting as environment variables the properties content
BRANCH=trunk
[JIRA] (JENKINS-12894) Building a scheme including multiple static library test targets fails under jenkins but works with xcodebuild from cli
ian carr created JENKINS-12894: -- Summary: Building a scheme including multiple static library test targets fails under jenkins but works with xcodebuild from cli Key: JENKINS-12894 URL: https://issues.jenkins-ci.org/browse/JENKINS-12894 Project: Jenkins Issue Type: Bug Components: xcode Affects Versions: current Environment: OSX lion server jenkins 1.450 xcode 4.2 plugin 1.3 glassfish 3.1 host Reporter: ian carr Priority: Blocker I have an XCode workspace with several projects, each building a static library target. Each library with it's own test target. I have created a scheme containing each of the 7 test targets each selected for build, test, run (7 targets in all) (parralel building is disabled in this scheme.) Checking out this workspace from git and running a manual xcodebuild and setting TEST_AFTER_BUILD completes the build successfully and runs the tests. I have also configured a jenkins build for this same workspace and scheme. Most of the targets build, but one generates compile errors when compiling the test target. The failures indicate redefinitions of objective c interfaces indicating multiple inclusions of header files. Since these files are #imported and not #included there should be no multiple-inclusion. And as mentioned in XCode or from a manual run of xcodebuild these errors are not appearing. I am wondering whether there are some additional environment variables being set in the jenkins invocation? or perhaps the mutiple target scheme is not supported? -- 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-8298) Reloading persona does not reloads existing persona quotes
[ https://issues.jenkins-ci.org/browse/JENKINS-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-8298. --- Resolution: Fixed Reloading persona does not reloads existing persona quotes -- Key: JENKINS-8298 URL: https://issues.jenkins-ci.org/browse/JENKINS-8298 Project: Jenkins Issue Type: Bug Components: persona Affects Versions: current Reporter: whren Attachments: persona.hpi, persona.jar, persona.zip When using the reload persona url, it does not reload personas quotes. It only loads potentialy new personas. Looks like a Persona.reload() is missing in hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-8298) Reloading persona does not reloads existing persona quotes
[ https://issues.jenkins-ci.org/browse/JENKINS-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159510#comment-159510 ] SCM/JIRA link daemon commented on JENKINS-8298: --- Code changed in jenkins User: Whren Path: src/main/java/hudson/plugins/persona/xml/XmlPersonaReloader.java http://jenkins-ci.org/commit/persona-plugin/bf35780e4b639db86d43fc56e6a47cb58b87d773 Log: [FIXED JENKINS-8298] Reloading persona does not reloads existing persona quotes When using the reload persona url, it does not reload personas quotes. It only loads potentialy new personas. Looks like a Persona.reload() is missing in hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). Signed-off-by: Whren wh...@free.fr Reloading persona does not reloads existing persona quotes -- Key: JENKINS-8298 URL: https://issues.jenkins-ci.org/browse/JENKINS-8298 Project: Jenkins Issue Type: Bug Components: persona Affects Versions: current Reporter: whren Attachments: persona.hpi, persona.jar, persona.zip When using the reload persona url, it does not reload personas quotes. It only loads potentialy new personas. Looks like a Persona.reload() is missing in hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-8296) Allow use of random persona instead of a fix one
[ https://issues.jenkins-ci.org/browse/JENKINS-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159511#comment-159511 ] SCM/JIRA link daemon commented on JENKINS-8296: --- Code changed in jenkins User: Whren Path: src/main/java/hudson/plugins/persona/QuotePublisher.java src/main/java/hudson/plugins/persona/RandomPersona.java src/main/java/hudson/plugins/persona/RandomPersonaFinder.java src/main/java/hudson/plugins/persona/simple/AbstractQuoteImpl.java src/main/java/hudson/plugins/persona/xml/XmlPersonaFinder.java http://jenkins-ci.org/commit/persona-plugin/2ac2d10efecf0e318d128910540c00c5cd35c6e4 Log: [FEATURE JENKINS-8296] Allow use of random persona instead of a fix one It would be great to allow per project use of a random persona at each launch of a build. How : In the configuration of a project, the Random Persona will be choose in the list of available personas. At each launch of a build the plugin will verify if the choosen persona is the Random Persona, if so this Random Persona will randomize the choose of one of the personas configured. The remaining process will be the same as today. The project quote and icon will of course reflect the last build. Signed-off-by: Whren wh...@free.fr Allow use of random persona instead of a fix one Key: JENKINS-8296 URL: https://issues.jenkins-ci.org/browse/JENKINS-8296 Project: Jenkins Issue Type: Improvement Components: persona Affects Versions: current Reporter: whren Attachments: persona.hpi, persona.jar, persona.zip It would be great to allow per project use of a random persona at each launch of a build. How : In the configuration of a project, the Random Persona will be choose in the list of available personas. At each launch of a build the plugin will verify if the choosen persona is the Random Persona, if so this Random Persona will randomize the choose of one of the personas configured. The remaining process will be the same as today. The project quote and icon will of course reflect the last build. Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-10166) Exception thrown during Persona finder on old format
[
https://issues.jenkins-ci.org/browse/JENKINS-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159512#comment-159512
]
SCM/JIRA link daemon commented on JENKINS-10166:
Code changed in jenkins
User: Seiji Sogabe
Path:
src/main/java/hudson/plugins/persona/xml/XmlPersonaFinder.java
http://jenkins-ci.org/commit/persona-plugin/2bce6a997cd632b4d849e3a0481bc7bf68c951fa
Log:
[FIXED JENKINS-10166] Exception thrown during Persona finder on old format.
Exception thrown during Persona finder on old format
Key: JENKINS-10166
URL: https://issues.jenkins-ci.org/browse/JENKINS-10166
Project: Jenkins
Issue Type: Bug
Components: persona
Affects Versions: current
Reporter: Vincent Carluer
Assignee: vcarluer
Fix For: current
Error line 87 on Windows installation
c:\Program%20Files\hudson\data\Plugins\active-directory does not exist.
Certainly due to space in Program Files.
for (FilePath xml : baseDir.list(**/persona.xml)) {
It works if i change catch IOException by Exception
--
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-8298) Reloading persona does not reloads existing persona quotes
[ https://issues.jenkins-ci.org/browse/JENKINS-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159513#comment-159513 ] dogfood commented on JENKINS-8298: -- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_persona #30|http://ci.jenkins-ci.org/job/plugins_persona/30/] [FIXED JENKINS-8298] Reloading persona does not reloads existing persona quotes (Revision bf35780e4b639db86d43fc56e6a47cb58b87d773) Result = SUCCESS Seiji Sogabe : Files : * src/main/java/hudson/plugins/persona/xml/XmlPersonaReloader.java Reloading persona does not reloads existing persona quotes -- Key: JENKINS-8298 URL: https://issues.jenkins-ci.org/browse/JENKINS-8298 Project: Jenkins Issue Type: Bug Components: persona Affects Versions: current Reporter: whren Attachments: persona.hpi, persona.jar, persona.zip When using the reload persona url, it does not reload personas quotes. It only loads potentialy new personas. Looks like a Persona.reload() is missing in hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-8296) Allow use of random persona instead of a fix one
[ https://issues.jenkins-ci.org/browse/JENKINS-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159514#comment-159514 ] dogfood commented on JENKINS-8296: -- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_persona #30|http://ci.jenkins-ci.org/job/plugins_persona/30/] [FEATURE JENKINS-8296] Allow use of random persona instead of a fix one (Revision 2ac2d10efecf0e318d128910540c00c5cd35c6e4) Result = SUCCESS Seiji Sogabe : Files : * src/main/java/hudson/plugins/persona/xml/XmlPersonaFinder.java * src/main/java/hudson/plugins/persona/RandomPersona.java * src/main/java/hudson/plugins/persona/simple/AbstractQuoteImpl.java * src/main/java/hudson/plugins/persona/QuotePublisher.java * src/main/java/hudson/plugins/persona/RandomPersonaFinder.java Allow use of random persona instead of a fix one Key: JENKINS-8296 URL: https://issues.jenkins-ci.org/browse/JENKINS-8296 Project: Jenkins Issue Type: Improvement Components: persona Affects Versions: current Reporter: whren Attachments: persona.hpi, persona.jar, persona.zip It would be great to allow per project use of a random persona at each launch of a build. How : In the configuration of a project, the Random Persona will be choose in the list of available personas. At each launch of a build the plugin will verify if the choosen persona is the Random Persona, if so this Random Persona will randomize the choose of one of the personas configured. The remaining process will be the same as today. The project quote and icon will of course reflect the last build. Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-12676) next-executions: Support evenly distributed crontab
[
https://issues.jenkins-ci.org/browse/JENKINS-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Albors reassigned JENKINS-12676:
Assignee: Ignacio Albors
next-executions: Support evenly distributed crontab
---
Key: JENKINS-12676
URL: https://issues.jenkins-ci.org/browse/JENKINS-12676
Project: Jenkins
Issue Type: Bug
Components: next-executions
Environment: Next Executions 1.03
Jenkins 1.450
Reporter: OHTAKE Tomohiro
Assignee: Ignacio Albors
Priority: Minor
Jenkins 1.448 added a new feature for crontab to distribute crontab evenly.
See
https://github.com/jenkinsci/jenkins/commit/b1bb3f66676b550971db08725d5c3cef5b42191b.
The issue is that next execution plugin does not support the new feature.
For instance, if a job is configured as crontab @daily,
next executions plugin says that the next will be 09/02/2012 00:00.
But actual next execution might be 09/02/2012 12:34 or 09/02/2012 01:23.
An unsafe workaround is to read private fiels of Trigger and CronTabList.
{code:title=NextExecutionsUtils.java}
@@ -25,9 +27,23 @@ public static NextBuilds getNextBuild(AbstractProject
project){
if(!project.isDisabled()){
Trigger trigger =
project.getTrigger(TimerTrigger.class);
if(trigger != null){
- ListCronTab crons =
parseSpec(trigger.getSpec());
+ VectorCronTab tabs;
+ try {
+ Field fieldTriggerTabs =
Trigger.class.getDeclaredField(tabs);
+ fieldTriggerTabs.setAccessible(true);
+ Field fieldCronTabListTabs =
CronTabList.class.getDeclaredField(tabs);
+
fieldCronTabListTabs.setAccessible(true);
+ CronTabList crontablist =
(CronTabList)fieldTriggerTabs.get(trigger);
+ tabs = (VectorCronTab)
fieldCronTabListTabs.get(crontablist);
+ } catch (NoSuchFieldException ex) {
+ ex.printStackTrace();
+ throw new NoSuchFieldError();
+ } catch (IllegalAccessException ex) {
+ ex.printStackTrace();
+ throw new IllegalAccessError();
+ }
Calendar cal = null;
- for (CronTab cronTab : crons) {
+ for (CronTab cronTab : tabs) {
Date d = new Date();
cal = (cal == null ||
cal.compareTo(cronTab.ceil(d.getTime())) 0)? cronTab.ceil(d.getTime()) :
cal;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12302) Remote call on CLI channel from [ip] failed
[
https://issues.jenkins-ci.org/browse/JENKINS-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159516#comment-159516
]
Kelly Robinson commented on JENKINS-12302:
--
Just ran into the same with 1.451 trying to use CLI to execute a groovy script
by url.
Remote call on CLI channel from [ip] failed
---
Key: JENKINS-12302
URL: https://issues.jenkins-ci.org/browse/JENKINS-12302
Project: Jenkins
Issue Type: Bug
Components: cli, groovy
Affects Versions: current
Environment: Jenkins 1.446, Linux CentOS
Reporter: Markus Hjerto
Assignee: vjuranek
I've had a KillStuckPolling.groovy job running for about 6 months without
problems, but on January 4th it stopped working with the below stack trace.
This matches with the release of Jenkins 1.446, which is currently installed.
I have tried to restart the server without any effect.
{noformat}
Killing all stuck SCM polls using ~/bin/KillStuckPolling.groovy
log4j:WARN No appenders could be found for logger
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
java.io.IOException: Remote call on CLI channel from /[ip] failed
at hudson.remoting.Channel.call(Channel.java:690)
at hudson.cli.GroovyCommand.loadScript(GroovyCommand.java:106)
at hudson.cli.GroovyCommand.run(GroovyCommand.java:93)
at hudson.cli.CLICommand.main(CLICommand.java:205)
at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:66)
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
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
at
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255)
at
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
at java.io.ObjectStreamClass.computeDefaultSUID(Unknown Source)
at java.io.ObjectStreamClass.access$100(Unknown Source)
at java.io.ObjectStreamClass$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.getSerialVersionUID(Unknown Source)
at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
at hudson.remoting.UserRequest.perform(UserRequest.java:98)
... 8 more
Caused by: java.lang.NullPointerException
at hudson.cli.CLICommand.clinit(CLICommand.java:448)
... 26 more
Build step 'Execute shell' marked build as failure
{noformat}
The groovy script is as follows:
{code:title=KillStuckPolling.groovy|borderStyle=solid}
Thread.getAllStackTraces().keySet().each() {
item -
println Checking item + item.getName();
if (item.getName().contains(SCM polling)
item.getName().contains(waiting for hudson.remoting)) {
printlnInterrupting thread + item.getId();
item.interrupt()
}
}
{code}
And the bash script used to start it is as follows
{code:title=KillStuckPolling.sh|borderStyle=solid|xml}
#!/bin/bash -e
echo ## Kills stuck polling jobs on Jenkins
if [ -z $JENKINS_URL ]; then
echo ERROR: This
[JIRA] (JENKINS-8296) Allow use of random persona instead of a fix one
[ https://issues.jenkins-ci.org/browse/JENKINS-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sogabe resolved JENKINS-8296. - Resolution: Fixed Allow use of random persona instead of a fix one Key: JENKINS-8296 URL: https://issues.jenkins-ci.org/browse/JENKINS-8296 Project: Jenkins Issue Type: Improvement Components: persona Affects Versions: current Reporter: whren Attachments: persona.hpi, persona.jar, persona.zip It would be great to allow per project use of a random persona at each launch of a build. How : In the configuration of a project, the Random Persona will be choose in the list of available personas. At each launch of a build the plugin will verify if the choosen persona is the Random Persona, if so this Random Persona will randomize the choose of one of the personas configured. The remaining process will be the same as today. The project quote and icon will of course reflect the last build. Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-12849) NullPointerException when parsing changeset
[ https://issues.jenkins-ci.org/browse/JENKINS-12849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159517#comment-159517 ] sogabe commented on JENKINS-12849: -- 0.10.1 is too old. use latest version. but I'm not sure that This plugin works on Hudson 2.2.0. NullPointerException when parsing changeset --- Key: JENKINS-12849 URL: https://issues.jenkins-ci.org/browse/JENKINS-12849 Project: Jenkins Issue Type: Bug Components: mantis Environment: Hudson ver. 2.2.0, Linux/Debian Reporter: Christoph Läubrich Assignee: sogabe Happens to me on Version 0.10.1 of the plugin ERROR: Publisher hudson.plugins.mantis.MantisIssueUpdater aborted due to exception java.lang.NullPointerException at hudson.plugins.mantis.Updater.findChangeSetsFromSCM(Updater.java:136) at hudson.plugins.mantis.Updater.findChangeSets(Updater.java:120) at hudson.plugins.mantis.Updater.perform(Updater.java:55) at hudson.plugins.mantis.MantisIssueUpdater.perform(MantisIssueUpdater.java:53) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:630) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:608) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:584) at hudson.model.Build$RunnerImpl.post2(Build.java:159) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:553) at hudson.model.Run.run(Run.java:1390) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145) -- 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-7209) Editing description results in broken utf-8 chars
[ https://issues.jenkins-ci.org/browse/JENKINS-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lehmann resolved JENKINS-7209. --- Fix Version/s: current Resolution: Cannot Reproduce this doesn't happen anymore, probably a locale issue Editing description results in broken utf-8 chars - Key: JENKINS-7209 URL: https://issues.jenkins-ci.org/browse/JENKINS-7209 Project: Jenkins Issue Type: Bug Components: description-setter Affects Versions: current Environment: Linux SLES, Tomcat 6.0.26, Java 1.6.0-20 Reporter: Alex Lehmann Assignee: huybrechts Priority: Minor Fix For: current When editing the description for a job, utf-8 characters get encoded twice resulting in broken characters (or rather 2 byte chars get encoded to 4 bytes). When editing the appropriate config.xml file manually, the text comes through ok, so this probably an error when processing the input text that is passed as url encoded form values. I couldn't reproduce this with hudson running on Windows, so it is probably a environment dependency or is affected by locale settings, but I couldn't get it right in Linux. -- 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
