Jenkins sending emails for manual builds - email

Does anyone know of a Jenkins plugin or script that would send out emails when someone does a manual build? We currently have a scheduled daily build for our dev env, but once in a while we need to do a manual build and I would like Jenkins to send an email out when this happens to warn our team that a build is in progress. But I don't want Jenkins to send out emails for the daily build because I think we all can agree that we get too many system emails.
Thanks

You can use the extended email plugin to send an email at the start of a build.
Obviously this means you will have to have separate manual and daily build jobs, but it's the best solution I've been able to come up with so far. If you use downstream job chains, you can still chain the same jobs to the manual and scheduled build so that the workflow remains the same and you don't need duplicates of all jobs in the chain.

Related

Best way to send email notification in an Azure DevOps build pipeline? Do not want to use "Notifications Module"

I would like to send email notifications as a task in my Azure DevOps build so that I can copy the build to other team projects and have it work automatically. I don't want to setup notifications for every new project I create. Thanks!
You can install the Send Email task from the marketplace, and add it to your build pipline.
The extension takes care of sending email within your build or release pipeline.
But better way is configure a global notification settings for the builds.
I tried to use "Send Email" to send something from my gmail but it didn't work out. I got the error message below
The SMTP server requires a secure connection or the client was not
authenticated.
If you have a similar problem, I recommend you using SendGrid. It's more easier.
Just create a resource "SendGrid" on Azure Portal.
Create an API Key from SendGrid.
Configure the pipeline with the key.
That's it. You don't have to config any SMTP setting and figure out what it is.
For an alternative solution, you can try CatLight notification tool.
It will show desktop alerts about build and release problems, as well as new PRs and work items.
You can configure a shared dashboard for the team, and select all relevant projects and pipelines there. After that, the team members will be notified about failed builds and releases. Team members can also update those monitoring settings themselves at any time.
Azure DevOps can send too many notifications, and when developers check their inbox, many of those notifications are outdated. So, after a while they configure filters to hide them, defeating the purpose of notifications in the first place. CatLight has a dashboard that will show a summary of active alerts, and they will disappear from it as soon as alert is resolved. So it will be less noisy, and harder to ignore than emails.
The tool is free for small teams and open-source, and their is paid version for companies.

Jenkins poll vs webhook

I am new to Jenkins, was curious to know how does the Jenkins poll feature works and how does it utlize system resources.
What could be best practice to use in CI system - Jenkins poll or github webhook and why?
This is a very easy answer, answered by Kohsuke, the creator of jenkins himself. Polling is less efficient, both for your computers, and for your people, since you have to wait--on the order of minutes--for your builds to happen, instead of them happening essentially instantly. We used to use polling before we switched to jenkins, and the biggest thing that people talk about is that "holy crap, jenkins builds fast." It's not jenkins, it's webhook pushing to trigger builds. Do that.

Fail/pass Jenkins job by email notification

We have an in-company system for creating production builds, and I need to create a Jenkins job to automate those builds.
There is a way to automate the launch of production build. But you can only know the results of the build by an email notification. Furthermore, you can only subscribe to notification using your personal domain credentials, i.e. the same login/pass that you use to log into your computer (and the password changes every month).
So now, Jenkins job is considered "pass" as soon as the build launches, and not when it actually finishes.
I wonder how to make Jenkins pass/fail the job with the given restrictions.
Additionally, I want to avoid:
hardcoding my personal credentials anywhere,
depending on my or anyone else's personal computer being turned on.
Ideas?
I'm not aware of any Jenkins plugin that is capable of receiving e-mails.
If you can manage to store the notifications' content in a file you could use the
Text-finder Plugin in the Post-build Actions of an additional monitor job that runs on a regular basis.
Have a look at Monitoring external jobs, too, whether this is useful for you.
UPDATE:
There is actually a plugin that receives e-mails: the poll-mailbox-trigger-plugin. Install it and do the following:
Create a new Freestyle project named e.g. Build Status Mail Monitor
Build Triggers → [✔] [Poll Mailbox Trigger] - Poll an email inbox
configure as desired
Build → Add build step → Execute Groovy script
◉ Groovy command: add code to change build launcher job's status

how to send email notification to developer for build failure in Jenkins

I have a continuous integration setup and integrated selenium scripts in jenkins. In case of failure in build, mail notifications should be sent to the developer who commited the changes. I run selenium scripts in jenkins to verify the status of the build. The problem is that if there is any failure, email notifications are sent to the selenium script developer instead of the application developer. It assumes that build is getting failed due to the changes made in selenium script but the actual issue is with the application code.
Is there any way to send mail to application developers for build failure instead of selenium script developer ?
I would have preferred to write this response as comment rather than answer, but due to insufficient rep, am posting it anyways.
If you want to send email notifications to particular email address, check out Email-ext plugin. With this you can add post build action of Editable Email Notifications and control which email address you send notifications and when(if your job fails or success)
First of all, use email-ext plugin as mentioned above. Secondly, ensure you select 'upstream committers' option. As per its own description: "Sends email to the list of users who committed changes in upstream builds that triggered this build." If your application build triggers a selenium build, this is what you need.

How to remove a user from recipients of Jenkins build failure email

I'm receiving daily "Jenkins build is unstable" emails for a project I'm no longer working on.
I can see from the build result (build.xml) that I'm in the list of "culprits", because of a commit I made some time ago, and since the build has been unstable for weeks, the list of culprits hasn't been cleared.
Since I'm no longer working on this project, I want to stop receiving email notifications from this Jenkins job. How can I remove myself from the recipients? Should I edit the build.xml of the last build? (EDIT: apparently this approach doesn't work)
It is possible, but a little complicated. First, you need to stop Jenkins or send it to quiet mode to avoid further builds.
As the actual list of culprits is calculated at runtime from all recently failed builds, you need to remove your ID from the culprits list in the build.xml of all failed builds (since the last successful one) where it is listed.
Finally restart Jenkins so the internal data structure is updated from the modified build.xmls.
So, if build 10 was the last successful one, you need to remove the ID from builds/11/build.xml, builds/12/build.xml, etc.
Could you just spam filter/block the email by title in your email client? Most Jenkins build emails will have a common title (with different only in status, build number). Builds from different jobs will have different common titles. So block the "offending" email by title.
To get Jenkins to 'release' you from the culprits, the build has to succeed. If you have access to the job configuration, you can make a fake success build (a simple "exit 0" in the command line will suffice), but this will clear all other culprits too.