[JIRA] [email-ext] (JENKINS-14508) Default pre-send script in Jenkins Configuration
Mac Cer
commented on JENKINS-14508
Default pre-send script in Jenkins Configuration
Hey, is it intended behavior to have the $DEFAULT_PRESEND_SCRIPT be expanded after a Job that had it included in its configuration ran?
Cause that's what happens with my Jenkins 1.509.4 and Version 2.36 of this plugin.
I find this a little inconvenient. What if I want to make changes to my script? Every Job that I have set up with "$DEFAULT_PRESEND_SCRIPT" in its configuration would have the old version of that script expanded in its configuration after it ran at least once. I would have to go through every job config and change it back to "$DEFAULT_PRESEND_SCRIPT" to have to load the newest version of that script.
This expansion happens every time. I tried writing it as $DEFAULT_PRESEND_SCRIPT and ${DEFAULT_PRESEND_SCRIPT}. Both times it gets expanded.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-20770) Default pre-send script variable gets expanded inside the job confguration
Mac Cer
created JENKINS-20770
Default pre-send script variable gets expanded inside the job confguration
Issue Type:
Bug
Affects Versions:
current
Assignee:
Alex Earl
Attachments:
config.xml, config_before_job_is_run.xml
Components:
email-ext
Created:
26/Nov/13 2:38 PM
Description:
I have a groovy script set in the global configuration for this email-ext plugin as a "Default Pre-send Script". Set it up as: ${SCRIPT, template="scan-email.groovy"}
I add this script to my job configurations as: $DEFAULT_PRESEND_SCRIPT in the field "Pre-send Script"
The script will get called at the appropriate time when the job runs. But after the job has run, inside the jobs configuration, there will no longer be the $DEFAULT_PRESEND_SCRIPT I originally entered. That field will contain the scripts contents. Aka, it expanded the $DEFAULT_PRESEND_SCRIPT variable with the content of the script.
Now, a setup like this will still work, but if I happen to edit this script, this job will not get the most recent changes I made to that script as it will just continue to use what is entered in its configuration.
Expected behavior:
I would have expected that $DEFAULT_PRESEND_SCRIPT stays as it is inside the jobs configuration. Pretty much like $DEFAULT_CONTENT does.
Please find attached a sample job configuration and notice the difference before and after that job has run.
Project:
Jenkins
Labels:
plugin
email-ext
Priority:
Minor
Reporter:
Mac Cer
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-20770) Default pre-send script variable gets expanded inside the job confguration
Mac Cer edited a comment on JENKINS-20770 Default pre-send script variable gets expanded inside the job confguration Sorry, you wrote "Use a local variable instead of reassigning to the origin class variable." in your last comment. Was this supposed to be "Used a local variable for the expanded presend script instead of reassigning to the original variable" as you wrote in that commit? I'm just wondering if I am to "Use a local variable instead of reassigning to the origin class variable." as you wrote in your last comment or if this was indeed something that was corrected in the code. If it was something that was wrong with the code, how long would you say does it take until this change is reflected in an update to the plugin? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-20770) Default pre-send script variable gets expanded inside the job confguration
Mac Cer commented on JENKINS-20770 Default pre-send script variable gets expanded inside the job confguration Sorry, you wrote "Use a local variable instead of reassigning to the origin class variable." in your last comment? Was this supposed to be "Used a local variable for the expanded presend script instead of reassigning to the original variable" as you wrote in that commit? I'm just wondering if I am to "Use a local variable instead of reassigning to the origin class variable." as you wrote in your last comment or if this was indeed something that was corrected in the code. If it was something that was wrong with the code, how long would you say does it take until this change is reflected in an update to the plugin? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-20986) Unexpected termination of slave channel during "Archive the artifacts"
Mac Cer created JENKINS-20986 Unexpected termination of slave channel during "Archive the artifacts" Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: core, ssh-slaves Created: 12/Dec/13 1:32 PM Description: Hello, I am currently receiving this Error during builds. SEVERE: I/O error in channel java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) This happens after the "Multi Configuration" Build ran successfully when Jenkins tries to archive the artifacts. The slave channel automatically reconnects but the build job is stuck indefinitely at the "archive artifacts" stage and has to be manually aborted. The slave channel in Question is a HP-UX B.11.31 ia64. A couple of important things to note: 1) This slave can also be used by an older jenkins instance running 1.431. 2) The Job being used was migrated from this old jenkins instance 3) The Job is a multi config job and builds successfully on all other architectures (SuSe, Solaris, Red-Hat) 4) The job runs successfully on the older jenkins instance! 5) There are no network issues responsible for the termination of the channel 6) Java issues on the slave are also not likely as I mentioned the exact same slave can be used without incident from the other jenkins instance Of course, I used a different FS root so that each jenkins instance could set up their own slave.jars etc. But other than that, the slave works without problems when building this job using the old jenkins instance but it will always fail on this slave during the "archive artifacts" stage of the build. Environment: Red Hat Enterprise Linux Server release 6.4 (Santiago) Project: Jenkins Labels: slave exception ssh Priority: Blocker Reporter: Mac Cer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [monitoring] (JENKINS-20947) Failed to monitor for Free Swap Space
Mac Cer commented on JENKINS-20947 Failed to monitor for Free Swap Space I am experiencing something similar which I posted here: https://issues.jenkins-ci.org/browse/JENKINS-20986 I also saw these "Failed to monitor for Free Swap Space" but since this was just category "Warning" I dismissed this. But in my case, the job also appears to hang at the "Archiving artifacts" stage and when I check the logs it says: "SEVERE: I/O error in channel java.io.IOException: Unexpected termination of the channel" It appears to terminate the channel when it should collect the artifacts. Via ssh my channel automatically reconnects but after that the job will still hang at the "Archiving artifacts" stage until I manually abort it. My older Jenkins install version 1.431 does not have this problem. There, the jobs can archive their artifact when using this exact slave. So I figure it must be a Jenkins problem itself rather than a slave problem. The slave works fine for an older jenkins install but a newer Jenkins install (version 1.509.4 LTS) has this problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [perforce] (JENKINS-21091) Config flip-flopping
Mac Cer commented on JENKINS-21091 Config flip-flopping I agree that this is very annoying. It is not every job and not after every run which makes it even weirder. I have the jobs' configs in Perforce, as well and it would be great if I could do some configuration on some jobs and then simply run "p4 reconcile" to get the deltas. Which should just be the things I just changed. But with this behavior, I will always get x other job changes checked in that really have not changed except for the firstChange property. Alternating between 0 and -1. I am wondering what that property is used for and what would happen if one manually deleted that row in the jobs' config xml... It would be a dirty workround, but in case that property does nothing important, one coudl remove that row of the xml with some awk or sed in a script that simply runs over every job config xml before one checks in ones changes. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
