I am using Jenkins 1.495.
The problem is that when concurrent builds are enabled emails will not be sent until all the builds finish.
I have followed the issue and it stems from the fact that all builtin email notifications actions all have triggers which are dependent on previous builds so that they can know if the current build is 'still failing' or 'fixed' or 'broken' or 'still success' etc etc. This can be easily seen here.
I want to know how to send emails without waiting for other builds, via:
An existing plugin that can solve my problem.
Write or adapt my own email plugin.
A clever solution that I would never have thought of.
If I am to write or adapt my own email plugin, I would like to know if anyone has any experience with this, or a solution they might already have that they could share.
I have a similar situation.
I am thinking of using a trigger parameterized build to trigger a secondary job to send out the email.
I decided I should put an answer here (it's been a few years since the question was asked)
I solved this by simply writing the email report myself, and not using the built-in.
I know this doesn't solve the problem, but that's my workaround.
In fact, eventually we simply moved the entire process from Jenkins to our own scripts, and just used Jenkins as a web interface.
Related
I have a gerrit - jenkins setup. Several jenkins jobs are started by a trigger based on a comment inserted to gerrit. The number of comment based triggers increases continuously. The project has a separate document with information what keyword in a comment executes what action.
It would be nice to provide a list of keywords directly in gerrit so developers do not need open documentation when searching for a specific keyword. Is there a way how to customize gerrit to show some hints when a user edits a comment?
Please follow the Checks plugin - currently is active development. It is/will be a complete redesign of how CI will do checks and how users interact with the CI checks being run. I don't think there's Jenkins integration for this already other than (custom) Groovy scripting polling the REST API at the time of writing.
The UI will allow users to trigger, re-run checks without the need for adding some magic comment! :-)
It's currently deployed on the Gerrit of Gerrit for purely optional checks:
So far (Gerrit 3.0.0) there isn't a way to do that.
Currently, Jenkins add as a user any known user of Jenkins plus any user mentioned in a commit message.
This effectively means that if you are managing several projects in Jenkins instance and each project with tenths of developers then it is really hard to maintain.
Another side effect is that JENKINS_HOME/users are populated with one xml for each of these users, so Jenkins becomes somehow unmanageable. Not the end of the world, that's true, but at the same time you start seeing users from outside of team/organization.
So, is there any way to disable this behaviour?
Thak you so much.
In order to prove that a team is not seeing another team jobs or folders I need to come up with a measurable solution that validate that.How can I test that each team member don't see each other jobs? Because using the UI to see and comparing with my eyes becomes really difficult with multiple of groups or users for instance.
I am using Jenkins Project-based matrix plugin and latest Jenkins.
The best way to do this is by creating a test user. In case you are using AD or Jenkins own user database, try assigning the same permissions to what you have given for team. This way you will know it for sure.
If there are any such security issues chances, Jenkins will raise a notification highlighting the security issue with that of plugin. Hope this solves the issue.
I have a custom field called "Detailed Status" in the issue page. After an issue is verified by testers, they will change the value of this field to "Ready for Deployment". After we deploy the latest code to the server, this should be changed to "Verified after Deployment".
At the moment, after every deployment there will be at least 10-15 issues which will require a developer to manually go to each issue and change the value of the custom field to "Verified After Deployment"
Is there a way I could automate this?
I went through the documentation - I found out the option to do a Bulk Edit but my project architect wouldn't hear of any manual intervention at all.
Event listeners wouldn't serve the purpose would they, since deployment is not a Jira event but an external process. Could this be done using a script ? By directly doing an update on the JIRA tables or so ?
Sorry for sounding very vague and ignorant, since I am quite new to JIRA customization. Any pointers would be appreciated. Thanks.
There is a REST API that can be used by a script to update the custom field in the issues.
Start with http://jira-python.readthedocs.org/en/latest/
or
https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Edit+issues#JIRARESTAPIExample-Editissues-Examplesofupdatinganissueusingfields.
Sounds like your QA takes action during the Dev process (on Dev/Test/Stage environment(s)) to verify the issue has been resolved, and again after the deployment to a Production environment. If this is true, you could modify your workflow to allow for status & transitions to automatically set the field via a Post Function.
If QA hits 'Pass', it sends the issue forward in the workflow where that action updates the field "Detailed Status", and if they hit 'Fail/Reopen' it sends it back to Dev along with the corresponding status you want on that custom field. This would meet the mandate of no manual intervention.
There are several free plugins that can accomplish this, and streamline your workflow so that it mirrors your development practices.
I've been looking for a way to have a user acknowledge a
ticket after it has been assigned to them. I don't know if
this is a built in feature or if there is a plugin that
will create a state/button for a user to accept a ticket
after it has been put in there queue. I would expect to
see something like this from the ticket window around
workflow or start progress but no amounts of digging
through configuration settings has turned anything
relevant up.
Does anyone know about this added functionality in JIRA?
Much thanks.
I did this by a custom workflow step. After an issue arrived to an assignee (with status New) he/she should move it to another step (with status Open). Until he/she does it, the issue is considered as not noticed/reached the assignee. Also I have had a report showing issues with New status for more than a predefined period of time.
I'm not aware of a ready-made plugin which performs similar task (perhaps, I should dig into my posts on Atlassian answers to discover some clues for other solutions).
As #Stan says above, a custom workflow is the way to implement this. The workflow functionality in JIRA is very flexible and as a result has a bit of a learning curve, but Atlassian's documentation is pretty good. Post back here if you need help.