I have Jenkins CI/CD dry run job that each developer can trigger. The question is, can each developer have permissions to stop/abort only his flows which he triggered or Jenkins doesn't support it?
The lowest level of authorization is project-based security via the Matrix Authorization Strategy plugin with Job: Build/Cancel and Run: Delete/Replay/Update.
You could use the build user vars plugin together with the Build Name and Description Setter plugin to add the ${BUILD_USER} to the build's name and/or description (with ☑️ Set build name before build starts) so that each dev knows which build to abort in case.
See also How to get the BUILD_USER in Jenkins when job triggered by timer?.
To restrict the build history to the currently logged on user set the build name to #$BUILD_NUMBER - Started by $BUILD_USER and see my user script Jenkins - Restrict build history to current user:
Related
I tried to connect my Jenkins server to VSTS repo by following this Link.
https://blogs.msdn.microsoft.com/devops/2017/04/25/vsts-visual-studio-team-services-integration-with-jenkins/
However, the options are different from the tutorial.
There is no way to set a rule for Pull Request, which is what I am trying to do.
I set a new build definition to make the Jenkins build work on every commit, but doesn't work for Pull Request.
To queue Jenkins job for VSTS pull request build validation, you can follow below steps:
Create a job in Jenkins
First, you need to create a job in Jenkins. If you have already create, then skip this step.
Create and configure build definition for PR build validation
Seems you already created a build definition named Jenkins, then add
Jenkins Queue Job task.
If you didn’t configure your Jenkins as an endpoint in your VSTS project, you can click New button to specify server URL, username and password to login the Jenkins.
Then specify the Jenkins job for queuing.
Note: If your Jenkins setup as a local server (the url as http://localhost:8080), then you need to queue VSTS build by private agent which also located in the same machine.
Add build policy as the target branch policy
In the build policy, you can set the Trigger as Automatic, the Policy requirement as Required, and the Build expiration is Immediately.
Now when pull request is created or updated for merging into the target branch, VSTS build will be triggered immediately, and the Jenkins job will also be queued during VSTS build.
I’m using Jenkins v 1.61 with Java 7. I have a Maven job set up, using SVN for Source Code Management. I have a “Run buildstep before SCM runs” set up (courtesy of the pre-scm-buildstep plugin) and a pre-build step (a short script) set up prior to the Maven goals being run.
My question is, if any of these steps fails, how can I get notified via email of the failure?
Use Jenkins Mailer Plugin, This plugin allows you to configure email notifications for build results.
Plugin ID mailer
Latest Release 1.18
Latest Release Date Sep 04, 2016
Required Core 1.625.3
E-Mail notifications are configured in jobs by adding an E-mail notification Post-build Action. If configured, Jenkins will send out an e-mail to the specified recipients when a certain important event occurs:
Every failed build triggers a new e-mail.
A successful build after a failed (or unstable) build triggers a new
e-mail, indicating that a crisis is over.
An unstable build after a successful build triggers a new e-mail,
indicating that there's a regression.
Unless configured, every unstable build triggers a new e-mail,
indicating that regression is still there.
How about combining pre-scm-buildstep, conditional-buildstep and any-buildstep plugin.
This should allow you to run a publisher step like sending email notifications on a regular build step or a pre scm build step (feature provided by any-buildstep plugin). You could also add a condition check (feature provided by the conditional-buildstep plugin) on the pre-scm-buildstep phase.
You've mentioned that you use a short script prior to the pre-scm-buildstep, just in case you're exporting environment variables as input for your conditional check, remember that you'll also need to write that to a properties file (SEND_EMAIL=true >> my-job.properties) and use env inject plugin to load them on your job environment variables, freestyle jobs don't persist exported shell variables on build steps to be visible to the next steps that come after it.
Lot's of plugins right? Quite annoying. If you want something more elegant, I would recommend using pipeline as code plugin and wrapping everything on a try/catch/finally block, so you could raise an exception before the code checkout stage given a failed check, there are some examples in this article.
We are setting up a continuous delivery pipeline in Jenkins, using the build pipeline plugin.
Our deployment steps uses a proprietary deploy tool (triggered by a HTTP request from jenkins), but we need to have an additional Jenkins step for acceptance tests on the then deployed project. So our deploy tool will need to trigger the last pipeline step.
The jenkins setup for this is obvious:
For a Manually Triggered downstream build step: To add a build step
that will wait for a manual trigger:
Select the Build Pipeline Plugin, Manually Execute Downstream Project check-box
Enter the name(s) of the downstream projects in the Downstream
Project Names field. (n.b. Multiple projects can be specified by using comma, like "abc, def".)
Source: Build Pipeline Plugin
The problem is: I can't seem to find a way to trigger this downstream build through a URL.
In fact I'd need the URL in the deploy job, so I can send it to the deploy tool as a callback URL. Can anybody help?
If I understand correctly, you want to use remote access API, which to my knowledge is no different between general project or pipeline one.
Take a look here:
https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API
Submitting jobs
Jobs without parameters
You merely need to perform an HTTP POST on JENKINS_URL/job/JOBNAME/build?token=TOKEN where TOKEN is set up in the job configuration.
As stated above by #rafal S do
read a file which has list projects name for which build job has to be triggered do a curl HTTP POST on JENKINS_URL/job/${JOBNAME from the file}/build?token=TOKEN within a for loop , where for loop has list of all project names from the file you read
Let's say I have this situation. I have three jobs. Job number one has two manually triggered downstream jobs (deploy to test, deploy to prod for example). Something like this:
I want the deployment jobs (test-job-2, test-job-3) to require a password before they are triggered. How can I solve this with Jenkins?
The only option right now supported by the Build Pipeline Plugin is to have a manually deployed downstream job. But this job starts right after you click on it. I would like to require the user to manually enter some parameters (password for example).
Is there some workaround? I was thinking of using the Promoted Builds Plugin. So the deployment jobs would run in a "dry run mode" - just checking that we have ssh access to the server and some other basic stuff. And then in order to deploy you will have to promote the build.
This approach isn't very nice though. Build pipeline and promoted builds plugins don't interact with each other very well.
This is not exactly what you want, but I guess it would some how solve your problem.
View Job Filters
Using this feature in tandem with a security feature such as the Standard matrix based security can help you create a view that will show different jobs depending on who is logged in.
I use different Jenkins Servers to "complete the pipeline" using Build Publisher job to publish the last part of the pipeline job to the other jenkins. I then pick it up from there. Operations teams have access to the "prod" jenkins system, and developers have access to the "dev" system.
On our Jenkins (1.492) I have the Claim Plugin installed. Jenkins is configured to use LDAP using matrix authorization.
After installing the plugin and enabling the plugin in the configuration of each job the /claim view says "Welcome to the Hudson Claim Report. There are no failing builds. Excellent work!" and does not list any builds to claim.
I have both unstable and failed builds.
I have rebuilt the failing and unstable builds after installing the plugin and configuring the jobs.
I have also changed the default view back to "All" - I read somewhere that there may be a problem.
I did also restart Jenkins.
I am logged in with an LDAP user.
The claim view does not list anything.
I have no claim icon in the build history of the job.
I have no claim link on the build page beneathe "started by user".
I have added a "Claim" column to a custom view with failing tests - but it's empty.
But I can claim a single regression via the test report view on a unstable build.
What have I missed? How can I find the problem?
In order to activate the Claim Plugin you must first add the 'Allow broken build claiming' action to the 'Post-build Action' section of one or more jobs. The next time the job fails after adding this step, it should be available to claim.
Configuring this on a large number of jobs is a bit of a pain but fortunately someone has contributed a Groovy script to allow broken build claiming on every job.