Open timja opened 12 years ago
This is a change to Jenkins core, not email-ext. Also, you are over complicating your setup. Use scripting to make modifications, not files.
giga:
Thanks Slide. Yep, I'll do that as a last option. Also, I thought again - if we achieve the above, we may land into an infinite nested loop during variable expansion. Otherwise, this would have been a great improvement.
ex:
if X=$Y and if Y=${VAR}-I_like_it and VAR=FIFA_$X.
Thanks a lot to "Slide" for resolving: https://issues.jenkins-ci.org/browse/JENKINS-14210
Improvement/Issue: (EMAIL-EXT - FILE token doesn't allow NESTED contents.)
Viewers: Before reading below, it's recommended to see the above link first (not required though).
==================================================================================================
Hi Slide,
Now, similar to the above request.
In the Editable email notification (Email-ext plugin), we have Subject, Recepients etc fields.
What I was wondering is if I can defined those in all of my Jenkins jobs as one variable like: $RECEPIENTS, $SUBJECT etc. Now, what I'll do is, I'll set these variables from a file that I'll use as a environment variable property file. i.e.
If I give C:\giga\email.config...txt as the environment file withing Jenkins JOB, then, inside this file, I'll set the variables for EMAIL variables like:
RECEPIENTS=abc@xyz.com, giga@fifa.com
SUBJECT=[$INSTANCE_NAME] Build $BUILD_STATUS: $PROJECT_NAME # $BUILD_NUMBER
or
SUBJECT=[$INSTANCE_NAME] Build $BUILD_STATUS: $PROJECT_NAME # ${ENV,var="build.label"}
NOW, seems like when I tried using this behaviour, I found that an environment variable IF containing another variable are NOT EXPANDING as well. Is there any way, we can achieve this too.
Now, your question towards me would be:
1. Why dont I use the above variables in the Jenkins job directly and remain silent / happy ???
Actually to answer it: I see the following conclusions:
1. As I have many Jenkins job, I want all the jobs to reflect MINIMAL configuration at the Jenkins setting i.e. if Email Ext "SUBJECT" box contains: $SUBJECT
only, then, it'll lot easier for the new user to understand and learn.
2. All the jobs will be SAME as far as EMAIL-EXT (Editable email notification) section is concerned. SAME in the sense of using the environment variables.
3. Definition of these environment variables DONT have to be defined at the Jenkins job level as we will create a config file and define the variables there and just use one variable name per box (for each Editable email notification fields/boxes).
4. If someday we need to change the subject,
FROM:
SUBJECT=[$INSTANCE_NAME] Build $BUILD_STATUS: $PROJECT_NAME # $BUILD_NUMBER
to>SUBJECT=[$INSTANCE_NAME] Build $BUILD_STATUS: $PROJECT_NAME # ${ENV,var="build.label"}
or
to>SUBJECT=Jenkins Build $BUILD_STATUS: $PROJECT_NAME # ${ENV,var="version.label"}
I dont have to go in Jenkins job configuration and change it there. I'll just change my config file and there you'll see the change in the email notification as Jenkins job's EMAIL SUBJECT box is stil containing $SUBJECT variable which's defined in our config file.
5. BASICALLY, what we need in the above request is...
similarly like you allowed nested contents in the JELLY script (EMAIL CONTENT area),
can we have the same "nested" capability in other parts of the JENKINS jobs where we specify some variables (it can be Email's fields/boxes, or it can be any field/box in Jenkins job's whole configuraiton).
What we want to achieve here is (30000 feet view):
if X=$Y and if Y=${VAR}-I_like_it and VAR=FIFA.
Then X should result as:
"FIFA-I_like_it"
Apart from that, when can we expect the nested funcationality of Jelly to be included in the next version of Jenkins build .war? Kindly advise.
Thanks.
Regards
Arun Sangal
Originally reported by giga, imported from: Jenkins Configuraiton boxes / fields doesn't allow NESTED contents.