Jenkins - Trigger email based on input parameter - jenkins

I have several Jenkins jobs where I want an email to be triggered (or not trigger) based on an input parameter.
The use case is that I have one deploy job per project, but that job is parametrized for each environment. We you run the job you can select which environment to deploy to (Dev1, Dev2, QA, etc). Ideally I would like to send out notification emails when a new build is sent to QA, but I do not want to send out notification emails when a new build is sent to Dev, because that happens all the time (with every developer commit) and would flood email boxes.
I've tried googling but haven't yet found a solution. I am currently using the email-ext plugin.
Thanks.

It is a very nasty way to solve the problem, but if you cannot do it by any other means...
Create a dependent job that exists primarily to pass / fail based on the value of the parameter, which would get passed as a parameter to the job. Then you could chain the decision the job made to the email notification.
Of course, if you were going to do this, it would probably be better to just write a small parametrized email sender using javax.mail and have Jenkins run it by "building" an ANT project that actually calls the "java" task. Then you have your own email sender (full control) and could make it a dependent job on the other tasks.
I hope someone chimes in with a simpler way...

In email-ext you can add a "Script - Before Build" or a "Script - After Build" trigger which will trigger on whether the specified groovy script returns true or false.
The help for the script reads:
Use this area to implement your own trigger logic in groovy. The last line will be evaluated as a boolean to determine if the trigger should cause an email to be sent or now.
They don't give many details of what's available in the script, but from the source code on Github, it looks like you have "build" and "project" at least, and some common imports done for you:
cc.addCompilationCustomizers(new ImportCustomizer().addStarImports(
"jenkins",
"jenkins.model",
"hudson",
"hudson.model"));
Binding binding = new Binding();
binding.setVariable("build", build);
binding.setVariable("project", build.getParent());
binding.setVariable("rooturl", JenkinsLocationConfiguration.get().getUrl());
binding.setVariable("out", listener.getLogger());
Caveat, I haven't tried this, but this should work as an example script:
build.buildVariables.get("MY_DEPLOYMENT_ENV") == "QA"
that should get the value of a String or Choice parameter you've created called "MY_DEPLOYMENT_ENV" and trigger the email if the current value is "QA"

Related

Modify notifications on a running build in jenkins

I occasionally want to get notified when a particular jenkins job that is building finishes. Is there any way to do this?
Scripting it through the API would be fine. I already have the jenkins IRC bot that notifies me of many things, so if I could just dynamically modify the running job build, that would be enough to do what I want -- I'm just having a hard time finding how to accomplish that.
AFAIK, you cannot change a job's config while it's running.
Here is an idea: Use a post-build step to check for an external resource status (like a file containing an action by text) and running an action based on the content of the file.
The external file can be modified while the build is running, so when the post-build is executed, it will follow the logic defined based on the content of the file.
I hope this helps.
You can use email notifier, It will send you an email
https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin

Setting Jenkins to email a build notification to the BitBucket user who pushed a branch

A project repository has been successfully connected to a Jenkins server using the BitBucket plugin, and a project set up such that:
Each push to a branch in BitBucket will trigger a webhook sent to the Jenkins server
When the Jenkins server receives the webhook it will build the changed branch (by specifying branch name as ** in the config)
After the build is complete a notification is sent back to BitBucket of the build status using the BitBucket notifier
Each of these has been easy to set up with just the instructions in the plugin and a few quick Googles. However I've now run into a problem which is maybe more a matter of wanting to run in an unconventional manner than anything else.
Using the normal emailer plugin or the Email-ext plugin it's possible to set emails to send to people involved in the creation of a build. For example the Email-ext plugin allows choice of:
Requester
Developers (all people who have commits in the build based off its last version)
Recipient list (a pre-set list)
Various "blame" settings for broken builds
The development process being followed involves each project being worked on by one developer in a named branch, e.g. userA/projectB. Obviously other developers could check that out and push to make changes but that's frowned upon. Even in that instance, the user who pushes the change to BitBucket should be notified.
None of the current settings support this. Requester is the closest, but that only works for manual builds. It seems a very simple requirement that the push to SCM that triggered a build should notify the user who pushed, but this is not documented anywhere that is easy to find.
After a lot of searching it seems the only way to accomplish this is by using a Pre-send script. This is added to the Advanced setting of the Email-ext post-build step, and takes the form of code written in Groovy which is a Java extension.
The script can take advantage of Environment variables, but is hard to test as there's no way to run the script with these in place. You can test simple Groovy scripts from Home -> Manage Jenkins -> Script console.
One important "gotcha" with the environment variables is that they are "included" in the script, rather than variables or constants. E.g. before the script compiles and runs, the content of the variable is pasted in place of its $NAME. In the example below the multi-line string syntax is used to include the BitBicket payload, whereas it might be expected that def payload = $BITBUCKET_PAYLOAD would simply work.
import javax.mail.Message.RecipientType
import javax.mail.Address
import javax.mail.internet.InternetAddress
import javax.mail.internet.MimeMessage
import groovy.json.JsonSlurper
def jsonSlurper = new JsonSlurper()
def bitbucket = jsonSlurper.parseText('''
$BITBUCKET_PAYLOAD'''
)
switch (bitbucket.actor.username){
case "userA":
msg.setRecipients(MimeMessage.RecipientType.TO, InternetAddress.parse("user.a#domain.com"));
break;
case "userB":
msg.setRecipients(MimeMessage.RecipientType.TO, InternetAddress.parse("user.b#domain.com"));
break;
}
The setRecipients command overwrites any existing recipient. Thus the recipient list or other email configuration should be set as a fallback for if the user is not recognised. Additionally, if there is nobody selected to send the email to, the script won't run at all. As added debugging, including the username in the body might help.
If the script fails, stack traces should be printed to the console log output of the test, and the build pass/fail shouldn't be affected, but the normal email address setup will be used instead. In stack traces look for lines with Script() in them, as that's the container which evaluates the Groovy script.

Executing Jenkins email-ext plugin not as last post-build action

I am using the email-ext plugin v.2.38.1 (post-build action "Editable Email Notification") on Jenkins v.1.566 to send e-mails after the build when certain conditions are met.
When using multiple post-build actions, I got the impression that the email-ext plugin always comes last and is executed after all other actions, no matter how I put the order of actions in the configuration. Other plugins respect the order and are executed accordingly as described in this issue.
Is there any possibility to execute another post-build action after sending the e-mails? In my case, I would like to run a shell script doing some clean-up in the workspace which cannot run before because it will delete a file that is part of the e-mail body.
One could work around this by defining an extra clean-up job which is triggered after the main job is completed, however, I would prefer having everything defined in one job only.
The emailing is a publishing action which occures always after build and post build actions ..
Additionally I think you should clean something before running the job (at startup eventually) but never at the end.
How can you study your issues if you destroy all materials that should enable you to do so ?
The step Editable Email Notification is always executed at last in the post-build actions, but you can use a Editable Email Notification Templates step which can be executed in the order you specified in post-build actions

can I configure build to happen every minute but deploy should happen only once a day in a single Jenkins job?

In a single Jenkins job, we can trigger a build by specifying a schedule and also by polling. But then, in both the cases, the build is triggered, and the deploy operation that I have configured as a post-build step (using PostBuild Task plugin) also happens. I want that the build happens whenever a change is detected by polling, but deploy should happen only according to the schedule I have provided.
Is it possible to do it in a single job, or do I have to configure 2 separate jobs for them ?
You said you are using PostBuild Task plugin. This allows to do a regular expression on the console log to determine whether to execute a task or not.
Builds started by schedule will have Started by timer at the top of the log. All you need to do is add this expression to your PostBuild step under "Log Text" field. If you are already using some criteria in there, click "Add" button to add another "Log Text" field, and use the "AND" operator between them
It will be cleaner to do it in 2 jobs. However, if you really need to have it in one job, you could use a combination of Jenkins plugins to do the job.
Use EnvInject Plugin to expose the BUILD_CAUSE and/or BUILD_CAUSE_SCHEDULED* environment variable(s). (This may not be necessary, you might be able to reference the Jenkins variables within the Jenkins configuration by default)
Use Flexible Publish plugin, post-build action, to set up a conditional publish step when BUILD_CAUSE == SCHEDULED, or when BUILD_CAUSE_SCHEDULED == true. (Just test one condition.) Note that you'll need to use Jenkins' expression syntax, like so:
${ENV,var="BUILD_CAUSE_SCHEDULED"}
* BUILD_CAUSE_SCHEDULED is not its real name, you'll need to find this out on your own, sorry.

To get build status through environment variable

I am using jenkins for continous integration.
For my build purpose, i triggering email using Ant task. I am not able to find an environment variable to pass ant for sending email build status(success/failure/stable).
i want to know how can i get environment variable for build status?..if not available, what is the alternative option for build status?
Thanks in Advance
varghese
Why use ANT to send emails from Jenkins when you have two great plugins that does just that?
The default mail notification is quite good, and if you would like to have more control
I suggest using the Email-ext plugin which is very comprehensive.
If still wish to use ANT to sent your mail-notifications including the status
you will have to break your process into two steps,
where the first part runs the build and the second one runs the ANT script to report the status.
In this case, you will need to trigger the second job from the first job via the Parameterized Build plugin -
see my answer here:
trigger other configuration and send current build status with Jenkins
The build status is not set until the job has finished running, so there is no easy way to push build status to a process triggered within the build itself. You could pull build status via the API, but this would have to be an externally triggered process due to the constraint mentioned above. Any reason you aren't using the built in email support or one of the excellent email extension plugins such as this one?

Resources