I am having two interdependent jobs, so my purpose is to send email notification to commiter of job-A after the completion of job-B.
For sending the notification i got a reply like i need to have fingerprinting between dependent jobs.
So my question is for fingerprinting, whether i needed to archive artifacts, i have finger print that artifacts or i can fingerprint whatever i file required for checking dependency between two jobs?
How can i send email notification on the basis of job-B(success/failure) to those who commit on job-A?
Please somebody explain it elaborately because I am new to jenkins.
Yes you need to archive artifacts and fingerprint them in order to create a dependency chain between your jobs. That way Job A build #256 with a fingerprinted item "some.file" will be linked to Job B build #1623 with the same fingerprint id of item "some.file".
In order to send email notifications when Job B fails you need to setup promoted builds.
Promoted builds allow you to define an action when a downstream project succeeds, breaks, fails, etc.. For example by sending an E-mail.
Related
Scenario:
Create an issue in org/bar whenever an action gets triggered by a PR in org/foo.
I've used the organization's private key to create a token to request https://api.github.com/repos/org/bar/issues for creating the issue, but the problem is if the PR is from a fork, the action can't access org/foo's secrets. So it means the action can't ready the private key from the secrets to create the access token.
The access limit description in the documentation: https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#using-encrypted-secrets-in-a-workflow
So, since GITHUB_TOKEN doesn't have access to other repositories in the organization, is there any other possible way to do the authorization for creating an issue on another repository using a GitHub action?
I think you could use the same approach as I did in Workaround to post comments from GitHub actions from forked repos :
create a cron job to regularly check for some condition (i.e. PR is created), and if condition is met, execute steps that require elevated privileges.
a PR could create some artifacts that cron job could use. Just make sure cron job is reasonably secure to not be manipulated into doing something evil.
I would like to create web service(s) that I can publish to external facing network to allow our customers team to send us CRUD operations on customer orders.
What would be the best practice in this case of using Microsoft or Open-Source technologies to serve the customer reqeusts?
Option1:
The web service accepts data XML/JSON
Stores the data locally in a file
A task picks up the file and attempts data load it in the background
Send an email for records that failed
Drawback here is the response from the web service will not be realtime and validation will be limited.
Option2:
The web service accepts data XML/JSON
Attempt data load
Respond immediately if load was success or failure
Drawback here is if the volume of orders increases increases several folds in near future if the infrastructure can handle it.
I am open to using REST with WCF or Web API and any other helpful technologies that can be scaled when demand grows.
Have you tried message queueing?
Basically, in this architecture, there is a client application (called producer) that submits a message to the message broker (message queue), and there is another application (called consumer) that connects to the broker and subscribes for the message to be processed.
The message can be just simple information or a task that will be processed by another application.
The application can act both as producer and consumer.
There are many message queue software, one of them is rabbitmq.
Here is the complete intro about this: https://www.cloudamqp.com/blog/2015-05-18-part1-rabbitmq-for-beginners-what-is-rabbitmq.html
Since the communication is done through the middleman (aka the message queue) it will not provide an immediate response. But you don't need to send the process result (i.e. Order processing in your case) to the email since the application can subscribe for the message of the result.
It is perfect to handle a huge load of processes. As always you can start small (even free) and scale up in the future.
Take a look at the pricing details https://www.cloudamqp.com/ that provides rabbitmq software as a service.
I do this using ActiveMQ as a central message broker (you can also use Azure Service Bus if you have an Azure subscription) and pre-baked domain objects. For your scenario it might look like:
The web service accepts data XML/JSON
yes, you have a REST service that accepts multipart requests, lets say JSON as it's easier to work with on the client side. Before you can send messages it's usually best to convert the incoming client message to a domain message, so all message consumers know the exact format to expect and can therefore validate the message. I usually create these using xsd.exe on Windows using an XSD file that describes the format of the object. xsd.exe turns that XSD into a C# class. It's then just a process of taking the JSON fields and populating an Order class. That Order then gets sent as a message to the broker. At that point you're now in guaranteed messaging land as JMS will take care of that and ActiveMQ will take care of message persistence.
Stores the data locally in a file
rather than a file, you convert the incoming JSON to a domain class, e.g. an Order instance. You'll never see JSON or XML beyond this point as it's all domain classes from here.
A task picks up the file and attempts data load it in the background
yes, the broker has routes defined in a Camel config that tells it to, for example, send messages coming in on the /client topic to the /orders topic. The task is set up as a durable topic subscriber so automatically gets that Order domain object.
Send an email for records that failed
if the Order object contains information about the client (email etc) then the task can send the email on failure but a better pattern is to route the failed Order to the /error topic where a different task, which again is a durable topic subscriber picks it up and logs/sends email/audits etc
if the volume of orders increases increases several folds in near
future
you can cluster the brokers and run multiple Order consumers. If you separate the failure handling into another route, all the order task has to do is process the order and route the message to either the /error or /success topic depending on the outcome. So each route provides a small piece of the puzzle and you can scale up the pieces if the puzzle gets too big.
I have job A and B.
Commit will be polled by job A and build is happening on Job B. So I did promoted plugin for email ext after completion of job B to send email from job A.
I have some periodic schedule task which run on job B itself. That case I needed to configure email triggering.
my problem is if i configure email for job B itself and promoted plugin email ext also..so when commit comes to job A. It will send email from promotion plugin + email I configured for job B. Here two email will trigger for commit job.
So I want to put condition on job B email notification?
Somebody please suggest a plugin that serve my purpose.
I'm not really clear on what is being asked here, but take a look at the Email-ext plugin and the Text-finder plugin. They may help you.
I want to send reports about every Hudson job build ito mail. Mail address must be get by certain rule, for example: committer - vpupkin, his mail - vasya.pupkin#co.com. I have script which makes this transformation. Is there way to do this?
If you are using an LDAP directory. You should be able to resolve the email address for a user through an email property of the user in the LDAP. Don't know if that also works with Active Directory (but you should be able to access your AD with the LDAP protocol).
The Email-Ext Plugin is the most feature-rich facility for sending out email from Hudson.
For example, it can be configured to email the committer(s) who made changes since the last successful build.
Yes, Email-Ext Plugin, as mentioned is the most feature-rich email pluggin for Hudson.
You can enable an option to mail every commiter for success, failure and other...
I don't do any transformations on the e-mails though... I am configuring the profile of every user, where I update their e-mail address using their actual one.
http://wiki.hudson-ci.org/display/HUDSON/RegEx+Email+Plugin
made for this plugin shell script, which generates its config
I am trying to configure Hudson to send an email if a build fails to the person who committed the broken build to SVN.
Question
Is it possible to do this and if so how do I configure Hudson to do it?
Yes - in your job configuration, check E-mail Notification under Build Settings near the bottom of the page, and then also check "Send separate e-mails to individuals who broke the build" to have Hudson email the person(s) who committed the SVN changes for a failed build. Note that your Hudson user names will need to match your SVN user names in order for this to work properly.
If you want to have certain people receive email whenever a build breaks or is fixed, regardless of whether they caused the failure, add their email addresses to the Recipients field.
You don't need the email-ext plugin to do this, but that plugin does give you a lot more control over the email format and content.
Yes, it is possible, and I do this in my organization. See:
http://wiki.hudson-ci.org/display/HUDSON/Email-ext+plugin
quoting:
This plugin allows you to configure every aspect of email notifications. You can customize when an email is sent, who should receive it, and what the email says.
This plugin extends Hudson's built in email notification functionality by giving you more control. It provides customization of 3 areas.
•Triggers - Select the conditions that should cause an email notification to be sent.
•Content - Specify the content of each triggered email's subject and body.
•Recipients - Specify who should receive a email when it is triggered.
The trigger you want to select is the "Failure" trigger, and be sure to check the "Send to Committers" checkbox.