This plugin automates feature/personal branch workflow on Jenkins
For general discussion of feature branches in Subversion, see Online subversion book or articles. Feature branches allow developers to commit their changes without worrying too much about regressions, and this Jenkins plugin assists teams to deploy this more easily.
You can have Jenkins create a branch in Subversion and create a job for it (by copying from the trunk build job) just by one click of a button.
To do this, first enable the feature branch support in the job that currently builds the trunk by clicking "Accept Integration from Subversion feature branches." This creates an action on the left to manage/create new feature branches. From this page, you can create a branch and the job:
Alternatively, you can manually create a branch, create a job, and enable the feature branch support after the fact by clicking "This project builds a Subversion feature branch" and specifying the trunk job.
Jobs that build feature branches get two actions on the left. One shows the status of the integration, meaning what changes in the branch has already been integrated into the trunk, the revision number of the integration commit, what trunk CI job has built it, etc.
The up arrow in the build history indicates builds whose output has been integrated upstream.
The other action in the project top page allows you to manually initiate the "rebase" action, which is a Subversion merge command to pull in the latest changes from the trunk into your feature branch, thereby synchronizing the branch with the trunk.
In addition to rebasing with the tip of the trunk, this UI allows you to pick arbitrary revision to rebase, in terms of the known build — for example, you can rebase with the revision that was resulted in the last stable trunk build, thereby eliminating any risk that you pick up regressions into your branch.
(This also works with the build promotion plugin and others that can define their own permalinks.)
Aside from manually performing rebase, you can also make rebase a part of the build. This can ensure that your feature branch always stay close to the trunk, thereby reducing the pain of the merge down the road.
Specifying the build to rebase to is a good way to control the frequency of the rebase. For example, imagine using the build promotion plugin on the trunk, and promote a build as "rebase point" about once a day (contingent on passing QA jobs.) Since the last "rebase point" build would only change about once a day, the automatic rebase would be no-op most of the time but only once a day.
In addition to initiate integration manually, you can also make Jenkins do integration automatically. This can be used as a publisher, as seen below:
If you enable this in a project, you'll be automatically integrating with every successful build. This is useful for personal branches, where you'll keep on committing to this branch and let Jenkins verify the change before it gets integrated into the trunk.
This feature gets more interesting in combination with the build promotion. You can keep producing CI builds quickly, then use other jobs to verify its quality, and as a promotion action you can make the integration happen. This matches more closely with the typical integration workflow.
Rebasing with the integration commit that was just made in rev\.\d+(see this discussion).
New permissions for Rebase and Integration will have to be granted manually on system using matrix-based authorization.
svn:externalswhen reintegrating branch (issue 23371).