Jenkins custom email notifications - jenkins

We run several environments within Amazon AWS and have a Jenkins server in each environment. Because we use the EC2 hostnames it's difficult to determine which environment the Jenkins is part of.
Therefore each Jenkins has a file called /etc/environment.txt which contains a environment name (e.g. "DEV4").
Question: How, in the email notifications, can I grab the contents of the file above and set it in the subject line of the email?
Would it be possible to overwrite the template? (I'm yet to find where the template file is..)
Thanks

You have many options:
Use the EnvInject Plugin to load a properties file. You need to change the file to become a valid properties file (the contents needs to change to something like env=DEV4).
define a global parameter (manage Jenkins -> configure System)
define an environment variable on OS level
All three solutions will provide an additional environment variable that can be used within the plugin.
Alternatively, just change the default template of the email notification (needs email ext plugin) to contain the env name.

Related

How to replace tokens found in files via Jenkins?

I use Microsoft Team Foundation Server (TFS) for most of my software deployments. TFS allows me to dynamically replace text within specific configuration files during the release process to specific environments (dev, test, prod).
The text it replaces are placeholders called "tokens". For instance, during my automated deployments, TFS will allow us to replace tokens found within configuration files with pre-defined values saved in the build administration for each environment. This way, I don't store any real credentials in source control for any environment. I also don't store any script in source that would hold these sensative credentials. The credentials are dynamically inserted over top the tokens during the release, and the credentials are hosted/saved/configured inside of the release system (not in a script).
For example, I have a configuration file (web.config) that has tokens. A token looks something like this:
MySettingName=${MYSETTINGVALUE}
During the release to DEV, I want the text ${MYSETTINGVALUE} replaced with the word TEN. During the release to PROD, I want that same ${MYSETTINGVALUE} text replaced with the word ORANGE. And I want to store those two values (TEN and ORANGE) in the release administration system, and not in a script.
How do I configure Jenkins to do this same thing?
I have searched up-and-down for this specific answer. While many blogs, articles, documentation exist, none of them speak directly to this issue.
I would prefer NOT to use some additional 3rd party software to do
this.
I would prefer NOT to kick off some manual build and supply these
values each and every time.
I would also prefer NOT to use an Operating System level system
variable (aka evironment variable). In case that server dies, I
would rather not have to remember to setup those OS environment
varialbles on the next server.
Jenkins has a built-in credentials plugin for handling secrets in builds.
See this article on how to use them: https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs
Basically it stores credentials securely and injects them into your jobs as variables which can then be used like any other.

Injecting more than one properties file into a Jenkins job

Right now I'm using EnvInject plugin to insert my environment variables through a properties file into my Jenkins job.
However, now I have a second job which needs the same environment variables as the first job and than some more additional variables which I would like to load via another properties file.
I know, there is a possibility to insert the values via Properties Content Edit field of the EnvInject-plugin, but I would like to keep it in a file, so it can be shared between jobs. But there seems to be no possibility to add a second properties file to EnvInject-plugin.
Is there any way to inject more than one properties file into a job or any other plugin, that could handle my scenario?
There is a simple way to get around the limitation you have.
You should load each file in the Build section, as a build step.
Use the Inject environment variables build step, and load each file you want. You can add multiple files by setting up multiple build steps of this type.
This works well for me on a similar need.
You can use Config File Provider Plugin to config some shell scripts.
You can add multiple files and then execute them.

Using environment variables with Jenkins

I'm building a group of projects from the SVN. There is a possibility of changing the SVN location time to time. As there are bunch of projects I hope to give the repository url with a environment variable so i can change all the url's easily. Any idea how to do that??
In Subversion Source Code Management, you can use variable in the Repository URL, simply type:
http://my.svn.com/path/to/${VARIABLE}
${VARIABLE} is a job parameters that is defined earlier. Never heard of anyone wanting to use actual environment variables for this, but you can try with the same syntax.
By default, it will give you a red warning that this is not a valid URL. You can disable this warning by going to Manage Jenkins -> Configure System and look for Validate repository URLs up to the first variable name. Put a checkmark there and save.

How do I access a configuration variable passed into grails from the commandline

I am trying to send a variable to my grails app through the command line similar to this:
grails -Dmy.build.number=33 prod war ROOT.war
I have tried to access it as grailsApplication.config.my.build.number but I get an empty map. It seems odd that the variable is defined but not set to what I send.
How do I access the command-line property?
I am planning on putting some of my assets(css,js,images,etc) in cloudfront to act as a cdn. So in my build phase I want to use the build number as a cache buster and set my assets to point to mycloudfronturl/assets/${buildnumber}/script.js. If there is a better approach, I'm open to that as well.
System.getProperty("my.build.number");

Hudson / Jenkins: share parameters between several jobs

I have about 20 jobs using common parameters (user, password), and sometimes the password expires... So I have to change it on all jobs, which is really time consuming (and error prone, I may forget one).
I thought about:
using a kind of magic property file if that exists to have directly lines like KEY, VALUE added into job parameters
adding the same kind of KEY, VALUE pair directly inside build.xml, but where ? And it's really ugly... Maybe with a dedicated XML embedded into the build.xml ?
calling a slave job that would (how ?) push up to the parent one the desired values...
As you can see I'm only starting in Hudson/Jenkins (I'm using Jenkins 1.424.2.2), thanks for your help !
EDIT: I'm not admin of the Jenkins instance, so I cannot have access to global properties...
Go to your Jenkins home and navigate :
Manage Jenkins >
Configure System >
Global properties >
Environment variables > ....
I can think of two approaches:
Use Global properties, found under Manage Jenkins -> Configure system. Here you can define environment variables that should be available to all jobs.
Write a small script that downloads, modifies and posts the job config: http://[jenkinshost]/job/[jobname]/config.xml.
You can read about the api capabilities under http://[jenkinshost]/job/[jobname]/api, here is what it says about reading and changing config.xml:
Fetch/Update config.xml
To programmatically obtain config.xml, hit
[http://[jenkinshost]/job/[jobname]/config.xml]. You can also POST
an updated config.xml to the same URL to programmatically update the
configuration of a job.
I eventually succeeded by:
keeping encrypted credentials in a web page
retrieving them in Hudson thanks to a shell script (wget), decrypt them, and creating a build.properties file in the workspace with lines name=value (in my case ssh.password=...)
This works, because Ant build steps detect this file and pass the variables inside into their context. Thanks to that I could centralize my credentials.

Resources