I'm using the Jenkins DSL plugin to automatically create build jobs for all branches of a git project. The DSL plugin is triggered by web hooks so that it is run immediately after a new branch was created. The generated build jobs for each branch are also configured to be triggered by web hooks.
The problem with the current setup is, that the build will only be executed after the second commit. The first commit will trigger the Jenkins DSL plugin to create the respective Jenkins Job and the second commit will then trigger the newly created job.
Is there any way, to start a Jenkins job immediately after it has been created by the DSL plugin? The only thing I can currently come up with is to add an additional build scheduling but I'd rather like to use web hooks only to prevent unnecessary polling.
You can use queue DSL command to schedule a build, see https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-DSL-Commands#queue.
To queue the job only if it's new, you need to use the Jenkins API to test if the job already exists.
if (!jenkins.model.Jenkins.instance.getItemByFullName('my-job')) {
queue('my-job')
}
Related
I have automated Jenkins master and slaves deployment and redeployment successfully.
I know how to manually create pipeline jobs and add github repos to use their Jenkinsfiles for the steps.
my issue is how can I automate the pipeline jobs addition to jenkins after its been destroyed and redeployed without having to manually create the pipeline jobs and point to Jenkinsfile each time.
I have seen this done before in a container environment with chef and docker when redeployed or updated it re-adds all the pipelines automatically again.
I want to not use the UI at all only to confirm job status progress and verify settings.
I would recommend looking at the JobDSL Plugin to create jobs, using a seed job to create them on initial Jenkins startup. The Jenkins Configuration-as-Code plugin can be used to setup any other configuration outside the jobs.
I'm trying to set up a scenario where a pull request is created on github that triggers a Jenkins multibranch pipeline, and where that multibranch pipeline uses the Generic Webhook Plugin to extract values from the POST request sent from github to jenkins to be used in the script.
Unfortunately, as described on the Generic Webhook Trigger Plugin wiki:
Note: When configuring from pipeline, that pipeline needs to run once, to apply the plugin trigger config, and after that this plugin will be able to trigger the job. This is how Jenkins works, not something implemented in this plugin. You can avoid this by using Job DSL and have Job DSL create pipeline jobs with the plugin configured in that DSL.
This would be OK using a normal pipeline since it would just be a one off on creation of the Jenkins job. The problem however is that a multibranch pipeline will create a new job whenever a new branch/PR is created, and that means that for each pull request I create on github (which triggers my multibranch pipeline script), I have to then run it twice to get the generic webhook functionality working. Having to resubmit for each PR would be tedious for long-run projects.
It seems to me like there are two possible approaches to solving/improving on this problem. One is to try and play around with DSL Jobs (as suggested by the wiki); but I tried this and couldn't get it to work (it was adding a huge amount of complexity to the set up, so I've abandoned it for now).
The second possible solution is as follows: when a PR is created in github, the Generic Webhook will cause a new job to be created in the multibranch pipeline corresponding to that PR; the first time the multibranch pipeline runs the first build of this newly created job will fail for the reason given in the quote above; but then a solution might involve testing that the first job failed and somehow telling Jenkins to try rebuilding for that job again.
So my question relates to this second approach: how can I most neatly run a rebuild for this multibranch pipeline upon the creation of a PR on github?
Any advice/suggestions would be appreciated!
For triggering multibranch pipline by webhook you can use this plugin:
"Multibranch Scan Webhook Trigger"
https://plugins.jenkins.io/multibranch-scan-webhook-trigger/
Actually that is not true for multibranch pipelines. Just ordinary pipelines needs to run twice.
I updated the docs like:
When configuring from pipeline (not multibranch pipeline)...
I have development code repository at bitbucket and another test script code repository at bitbucket. Now I have setup a Jenkins job by linking test code repository. Is there any way to trigger jenkins job automatically on change in development repository ?
You can add the BitBucket Plugin to your Jenkins instance. It will allow you to configure a webhook in BitBucket that will then trigger any Jenkins job listening for that webhook. The plugin's page has a detailed breakdown, but the basics are;
In your repo in BitBucket, create a new Webhook using your Jenkins' url. I believe the url is generally http://[your jenkins url]/bitbucket-hook/
Make the trigger a repo push.
In your Jenkins job, check the box "Build when a change is pushed to BitBucket" under the Build Triggers section.
Now any time you commit to the repo you created the Webhook on, that Jenkins job will be run.
You can also limit what branches trigger commits by parameterizing your Jenkins build to ignore certain branches / keywords / etc if that's something you need for your specific project.
Builds by source changes
You can have Jenkins poll your Revision Control System for changes. You can specify how often Jenkins polls your revision control system using the same syntax as crontab on Unix/Linux. However, if your polling period is shorter than it takes to poll your revision control system, you may end up with multiple builds for each change. You should either adjust your polling period to be longer than the amount of time it takes to poll your revision control system, or use a post-commit trigger. You can examine the Polling Log for each build to see how long it took to poll your system.
Alternatively, instead of polling on a fixed interval, you can use a URL trigger (described above), but with /polling instead of /build at the end of the URL. This makes Jenkins poll the SCM for changes rather than building immediately. This prevents Jenkins from running a build with no relevant changes for commits affecting modules or branches that are unrelated to the job. When using /polling the job must be configured for polling, but the schedule can be empty.
I'm running an ant job that runs several thing on master node and need to trigger several jobs on slave servers based on the options i select from the main job parameters
is there a way to call another job from within ant script without using jenkins-cli.jar as external command
You can trigger Jenkins jobs by doing an HTTP request:
Go to your Job Configuration
Build triggers > Check 'Trigger Builds Remotely' and think of an access token, e.g. SOME_SECURE_TOKEN.
In your ant script: execute a POST request to JENKINS_URL/job/JOB_NAME/build?token=SOME_SECURE_TOKEN
Note that if you have authentication in place, you need to set up a user who is authorized to start the other jobs. In that case read this more detailed explanation: https://www.nczonline.net/blog/2015/10/triggering-jenkins-builds-by-url/
Another solution would be to use the Parameterized Trigger Plugin to trigger builds from a Jenkins step. You mention that the jobs that need to be triggered may depend on the job parameters. In that case you can combine the Conditional Buildstep plugin with the Parameterized Trigger plugin.
I want to do a very simple thing - for every new pull request that is being created under my repo, I want to create a new jenkins job with similer configuration (run some batch), that will checkout the branch that is being merged (not the destination branch).
I will also like to delete this job after the pull request is approved, but that's not as important.
How do I do that? Every jenkins plugin that I found creates jobs for all my branches, or for a specified list of branches, instead of just for new ones or just unmerged pull requests
Here is one way you could solve this:
Create a template job containing the logic you want to do for each new branch (i.e. run some batch).
Create a job that is started for every new pull request in your repo. You could probably do this with the Script SCM Plugin using a short groovy script.
Inside this triggered job, clone the job in #1 using the Jobcopy Plugin. Replace any strings (e.g. git url) with whatever is needed to get the job working.
You could write another job that is triggered via the Script SCM Plugin when a branch needs to be deleted. You can remove it using the Groovy Postbuild Plugin.
OK I finally succeseeded, and it was WAY EASIER then I thought. I found a jenkins plugin called "Bitbucket pullrequest builder plugin", and it makes it incrediblly ease to build jobs for pull requests. The only thing is that I couldn't make it work with any OAuth consumer, and had to give it my own credentials. But other then that it works beautifully.
This is very similar with what we did in our team (We have more than 10 development branches and also a lot release branches)
I think the easiest way is as follows:
Plugin should be used:
gerrit trigger plugin
Used to get triggered when there is new commit come in
job dsl plugin
Used to generate the jobs based on the dsl script
build flow plugin
Used to define the execution flow
Create a Jenkins build flow job "EntryPoint" (This job will be triggered if there is a new commit push for review)
Create the a job generator job (This job will invoke the job dsl script to generate the template jobs based on the input parameter, such as branch)
Create a new job to do the cleanup work or as Daniel said, you can do it with groovy post build
Inside the build flow job, a simple flow as follows
//Get current branch from gerrit trigger plugin
def currentBranch = params[GERRIT_BRANCH]
//Invoke job generator job and pass the branch info to it
build ("job_generator",BRANCH:currentBranch )
//Invoke the generated job by job_generator
build("$currentBrnch_Build")
//Remove the generated job
build("CleanUpJob")