I am using the "P4 Plugin" - https://wiki.jenkins-ci.org/display/JENKINS/P4+Plugin in Jenkins v2.32.1.
I would like to trigger specific jobs in Jenkins, depending on what path is changed in SCM.
For example if something changes in
//depot/branchA
Build job A. If something changes in
//depot/branchB
Build job B.
As far as I can tell the plugin is only set up to trigger every job in Jenkins that has "Perforce triggered build." (building both A and B jobs) Am I missing something? I am currently using SCM polling and trying to move to a more efficient system.
This understanding is based on reading the "Triggering" section of https://github.com/jenkinsci/p4-plugin/blob/master/SETUP.md
You may be defining too broad a workspace, and causing Jenkins to trigger on every submit. The client workspace associated with job A should only map //depot/branchA/..., and the workspace for job B should only map //depot/branchB/....
Jenkins polls for changes, and if it sees any, triggers any build that has a matching path. So if both jobs had a workspace that mapped //depot/... then submits to branchA or branchB would trigger both jobs.
Related
On my current project, I have several dozen "sub-projects", each with trunk and branches (legacy setup, can't change it)
There are multiple commits on a branch, let's say 5, and then a branch is reintegrated to trunk. When a branch is reintegrated to trunk, it triggers trunk build as a downstream job.
I need this downstream trunk build to show all upstream SCM changes since last reintegration
I've used Display Upstream Changes plugin, however that only displays the last upstream commit in corresponding trunk build.
I've also used All Changes plugin. It does allow me to see "aggregate" list of upstream commits (either by date, promotion or number), but I cannot post these to downstream job.
Note: using SVN for SCM
Alternatively
Alternatively, if there is a way to include "merged revisions" in the SCM changelist, that would solve my issue as well
Jenkins naturally shows changes on a job.
A downstream job is linked only in a workflow sense. Do Job B after Job A. Linking two jobs in this way does not extend to showing changes.
Option 1
MultiJob Plugin
Option 2
You could get the list of changes in job A using groovy like this and pass it to Job B as a parameter to do something with. (Like print out to an HTML file and publish to the dashboard of Job B with the HTMLPublisher plugin).
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 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")
I have a Jenkins task that triggers on any changes made to a gitlab project.
There are a few situations I'd like to be able to set up, however I'm not sure how to best accomplish them. Most of it centers around being able to do the following:
Once the job is complete, I'd like to trigger another job that takes the contents of the first job's workspace (emptying out the initial one).
I'd like for a way to only run certain other jobs when the workspace contains a specific branch (automatically deploy develop branch to a preview environment).
"to trigger another job that takes the contents of the first job's workspace" see Shared workspace plugin:
This plugin allows to share workspaces by Jenkins jobs with the same SCM repos.
This question is similar to the question being asked at How to configure a single Jenkins job to make the release process from trunk or branches? however in this case Perforce is the SCM being used within Jenkins. Currently in Jenkins I have the following:
One release job per branch/trunk.
Each job has a separate Perforce workspace mapping the necessary branch/trunk
Upon running the job, the jenkins-perforce-plugin synchronises the complete workspace and then runs the maven release plugin.
Ideally I would like to have one release job that can point to any branch, synchronise to the code from that branch and carry out a maven release. However, with Perforce workspaces, I will require a view mapping for each branch/trunk. Is there are way to tell the jenkins-perforce-plugin to only synchronise to a particular view in the workspace view? This way I could build the release job with a parameter that passes in the branch path and the jenkins-perforce-plugin synchronises to jobs perforce workspace to this path only and then carries a build from there.
If I were trying to implement this as described I would created a parameterized build where I could hand in a Perforce label name. The Perforce Jenkins plugin can sync to a label; I would create labels for each release specifying the paths that should be synced and with a revision specifier of #head.
Jenkins should then sync just the files you want for that build. The workspace would of course map everything; the labels will specify the files to fetch.