[JIRA] (JENKINS-16195) jsplumb graph not working on InternetExplorer
domi commented on JENKINS-16195 jsplumb graph not working on InternetExplorer I don't have access to a win PC @home either, therefore I followed this instructions to get a VM up and running on my MAC: http://osxdaily.com/2011/09/04/internet-explorer-for-mac-ie7-ie8-ie-9-free/ After this, you can run your normal test-env with a specifig port (sudo mvn hpi:run -Djetty.port=80) and from within IE in your VM you can access it with this address: http://10.0.2.2 . Don't forget to change the "Jenkins URL" in the gloabl config to "http://10.0.2.2" too, otherwise you CSS will not load (that was my first error) By going through my setup I found that I forgot to change "Jenkins URL" and after adjusting it, I got a bit further, the boxes are now displayed, but they look really ugly (see new screenshots). The only warning I get in IE is this one: "SEC7115: :visited and :link styles can only differ by color. Some styles where not applied to :visited. jsplumb" While reading through the jsplumb documentation, I found this: ...if, for some reason, you set the render mode to be jsPlumb.VML but you're in any browser other than IE, jsPlumb will use SVG. so I changed... from: jsPlumb.setRenderMode(jsPlumb.SVG); to: jsPlumb.setRenderMode(jsPlumb.VML); it might be OK, but it did not really change anything. Unfortunately I'm away for about the next three months so I'm not able to work on this... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16195) jsplumb graph not working on InternetExplorer
domi updated JENKINS-16195 jsplumb graph not working on InternetExplorer Change By: domi (26/Dec/12 7:57 AM) Attachment: screen-capture-18.jpg Attachment: screen-capture-19.jpg This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15156) Builds Disappear from Build History after Completion
sogabe updated JENKINS-15156 Builds Disappear from Build History after Completion changed priority to Critical. Change By: sogabe (26/Dec/12 7:03 AM) Priority: Major Critical This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15156) Builds Disappear from Build History after Completion
Yong Guo edited a comment on JENKINS-15156 Builds Disappear from Build History after Completion I have this problem after upgrading to 1.494. Master/Slave setup (all Linux box). Only the job create after upgrading has this problem. Those jobs created before upgrading work well. (updated) I find all the builds exists in the build directory. The problem is that they are not shown in the build history. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15156) Builds Disappear from Build History after Completion
Yong Guo commented on JENKINS-15156 Builds Disappear from Build History after Completion I have this problem after upgrading to 1.494. Master/Slave setup (all Linux box). Only the job create after upgrading has this problem. Those jobs created before upgrading work well. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15915) Password Parameter should not be stored (on disk)
Gregory Boissinot updated JENKINS-15915 Password Parameter should not be stored (on disk) Change By: Gregory Boissinot (25/Dec/12 7:57 PM) Component/s: mask-passwords This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16192) xUnit plugin is using ancient XSL transform for NUnit, misses skipped tests
Gregory Boissinot resolved JENKINS-16192 as Fixed xUnit plugin is using ancient XSL transform for NUnit, misses skipped tests Change By: Gregory Boissinot (25/Dec/12 7:07 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16192) xUnit plugin is using ancient XSL transform for NUnit, misses skipped tests
SCM/JIRA link daemon commented on JENKINS-16192 xUnit plugin is using ancient XSL transform for NUnit, misses skipped tests Code changed in jenkins User: Gregory Boissinot Path: pom.xml http://jenkins-ci.org/commit/xunit-plugin/8364a0e4de6b333572c485a695832146c8bc6507 Log: Update to dtkit-default-junit 0.33 for fixing JENKINS-16192 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16192) xUnit plugin is using ancient XSL transform for NUnit, misses skipped tests
Gregory Boissinot commented on JENKINS-16192 xUnit plugin is using ancient XSL transform for NUnit, misses skipped tests Thanks for your remark. However for the future, xUnit plugin is now a based-plugin and the I strongly recommend the Nunit author to extend the xUnit plugin. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16198) Redeploy Artifacts functionality add ability to change build's status according to redeploy status.
Vladimir Kravets updated JENKINS-16198 Redeploy Artifacts functionality add ability to change build's status according to redeploy status. Change By: Vladimir Kravets (25/Dec/12 2:02 PM) Summary: Redeploy Artifacts functionality . Be able add ability to change status of build after 's status according to redeploy status . This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16198) Redeploy Artifacts functionality. Be able to change status of build after redeploy.
Vladimir Kravets created JENKINS-16198 Redeploy Artifacts functionality. Be able to change status of build after redeploy. Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: maven Created: 25/Dec/12 1:59 PM Description: In some cases can be happen that build was failed due to issue with nexus and build is ok, since deploing only fail. In this case will be great to change build status after redeploy according to redeploy procedure. I see this as "Change build status accoriding to redeploy status" checkbox in advanced setting. Project: Jenkins Priority: Major Reporter: Vladimir Kravets This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16197) Job run via cli with -s is not aborted on client abort
Alex Vesely created JENKINS-16197 Job run via cli with -s is not aborted on client abort Issue Type: Bug Assignee: Unassigned Components: cli Created: 25/Dec/12 10:35 AM Description: Jenkins changelog for version 1.494 specifies the following: If the CLI client is aborted during "build -s", abort the build. I am using 1.495. I have created a job with one shell command: "sleep 1000". I am running it via the CLI and specifying the -s option. The job starts successfully. However, when I kill the CLI client using ^C or "kill -9", the job continues to run. Anonymous users can start and cancel all jobs on my Jenkins. Am I doing something wrong? Environment: SLES 10 Project: Jenkins Priority: Major Reporter: Alex Vesely This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16129) Jenkins exception with parameterizedtrigger plugin
Alok Kumar commented on JENKINS-16129 Jenkins exception with parameterizedtrigger plugin Yes, I am and I am using the latest one. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7946) API: update job
Karel Vervaeke
commented on JENKINS-7946
API: update job
This is probably an old issue.
As far as I can tell you can update an issue by posting to /job/{jobname}/config.xml with the config.xml int the body.
There still is a problem: when you GET the job config and then POST it back you would expect it to be a no-op =>
curl http://myjenkins/job/myjob/config.xml -o myjob-config.xml
curl -XPOST http://myjenkins/job/myjob/config.xml -d @myjob-config.xml
However this operation strips newlines, breaking shell steps:
echo "one"
echo "two"
echo "three"
becomes
echo oneecho twoecho three
(in fact the entire config.xml ends up on a single line).
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
