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")
Related
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 am new to Jenkins. 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 a build when code is pushed in develop repo?
I tried many times by pushing change in develop repo, but it does not triggers the jenkins job.
You can configure the Jenkins trigger as an SCM poll.
You will have to enter a cron expression for the polling time period, like:
*/5 * * * *
This means polling from 5 to 5 minutes. If any change is detected, then the build is triggered.
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.
You can use webhooks to trigger build automatically. There are few options how to use it. See the following articles: this, this and this.
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.
To give some context the question is about GitLab and Jenkins setup.
I know how to setup a web hook, I know how to setup a job to be triggered by the hook. The problem is that I need to have multiple jobs and only a single entry-point (parent job) trigger for them.
The downstream jobs at the same time need to be git repo aware so I have to set repo url for them. This causes them to be triggered independently by the hook and I don't want that as this means that they are triggered twice.
On the other hand if I don't configure repo url on a downstream job and the parent job triggers it, it fails as it is not able to do a checkout.
I may try to hack around with some 'execute shell' build step, I believe it's not a valid way to go. Has anybody a good tip how to solve that?
For the reference here is the GitLab Jenkins plugin documentation according to which:
Plugin will parse the GitLab payload and extract the branch for which
the commit is being pushed and changes made. It will then scan all Git
projects in Jenkins and start the build for those that:
match url of the GitLab repo
match the configured refspec pattern if any
and match committed GitLab branch
I tried playing around with different settings, without a great result though.
For the project you want to get only local triggers, just enable Don't trigger a built on commit notification in the Additional behaviours of git plugin.
(https://github.com/elvanja/jenkins-gitlab-hook-plugin/issues/11#issuecomment-35385032, as you actually have discovered).
But a better solution could be to make your downstream jobs reference the repository locally cloned by main job (not sure if actually possible), so the plugin will never consider them for schedule a build, as the git url don't match.
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')
}