I know how to provide build parameters:
wget --post-data='json={"parameter": {"name": "testparam", "value": "HELLO"}}' http://jenkins/job/Job1/build?delay=0sec
But, is it possible to provide a shortDescription and userName in a Jenkins remote API build request via wget/curl?
How should it look like in json or xml? Is there any manual/guidance on the net?
I will use this in along with the problem described in Trigger dynamic set of jobs. I want to provide triggered job with the calling job name and build number.
You may consider using Jenkins CLI (http://[jenkins-host]/cli for help in the browser). You can specify a user to a build CLI command. I'm not sure what you mean by short description when starting a build, though.
Update: Please see Jenkins Wiki Authenticating Scripted Clients. I've created a user foobar ('full name' Foo Bar) and tried the following:
wget --auth-no-challenge --http-user=foobar --http-password=[apiToken] http://jenkins.yourcompany.com/job/your_job/build
Where the token is obtained from user configuration page: http://localhost:8081/user/foobar/configure. It worked. The user has to exist, though. Also, you must specify --auth-no-challenge option, otherwise it kicks off the build as anonymous. The status description says Started by user Foo Bar.
Another Update If everything else fails, you may consider the following workaround: start all builds via the Parameterized Trigger Plugin with an additional boolean parameter that tells the triggered job whether to run or not. In case the job is asked not to run it would fail immediately and call a 'clean-up' job passing to it the build info; the clean-up job then will delete the build from the system.
Related
How to submit the Jenkins job using curl api and get its buid number ?
Note - i tried with the following api, but its not printing any build number.
curl -X POST http://<hostname>:8080/job/<jobname>/build
In general, you can't do this: when you submit (or "trigger") a Jenkins job, this will not necessarily create and start a new build.
When triggering a job, only a request for starting a new build will enter the build queue. Depending on the availability of suitable executors, the actual build will be created (and started) immediately, later, or never at all. Also, multiple queued requests will normally be "squashed", so several submits will result in the same build number.
Bottom line: this can be done (with the constraints mentioned before), but it will require additional (Groovy) scripting for tracking the submit request through the build queue until the build will be started by Jenkins.
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.
Currently in order to enable or disable a job, a user must have Job Configure permissions in the Matrix-based security configuration.We would like to be able to manage the enable / disable job permission independently from the job configure permission.
There are some nightly jobs that we want every user to be able to enable and disable the project without touching/breaking the configuration.
Thanks
Provide a script for the users that will do this using the credentials of 'root' user and set only the execute bit on the script so that no one can read/copy it.
At least 3 ways to make a script:
HTTP POST request:
1.
curl -X POST http(s)://<your_jenkins_url>/jenkins/job/<nightly-build_job_name>/disable
2.
Use python JenkinsAPI.
Documentation is very good, easy to understand much like the API.
3.
The third one can be a script which will use jenkins-cli: accepted answer describes this well .
The Job Configure permission is bounded to the disable/enable function in each job, that's true.
One alternative to disable/enable jobs without the corresponding permission is to create new jobs which do this internally. For example, a job that needs job names as parameters, and disables them.
You could use curl + credentials of a Jenkins user with the Job Configure permission.
You could use plugins. For example, this script using the Job DSL Plugin:
job("jobname"){
using("jobname")
disabled(true)
}
For other options, check out this question.
You may try to install this plugin to get the enable/disable button for the individual project-
I checked in my Jenkins and I could see this:
But when I checked under plugins section I don't see this extra column plugin installed. Probably this is the default behavior in latest versions of Jenkins.
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?
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"