View Pretested Integration on the plugin site for more information.
Alexander Winther Uldall
Ronni Elken Lindsgaard
This plugin lets Jenkin manage a repository – keeping it in a clean state by only pushing changesets which build successfully. Builds – and thus repository updates – are triggered when developers push to another specific designated repository.
The system defined in this plugin depends on three parts: An 'upstream' repository where developers can pull the latest stable version; a 'downstream' repository to which developers push their changes and from where Jenkins extract changesets in order to build them and possibly commit them to the 'upstream' repository; and thirdly – in the case of distributed SCMs – the local repositories where developers work.
The current version is a minimal working example and – as it is under development – there are some constraints to the plugin as it is:
- Although the final plugin will support the most common SCMs – or at least allow for easy integration – only Mercurial is currently supported.
- Only successful builds are supported. Problems during merge/build leaves the workspace in a non-working state, which must be fixed manually by clearing the workspace for the time being.
In order to get started using Pretested Integration, you need the three repositories described above: The 'upstream' and local repositories probably exist already. Otherwise, you must set up a remote Mercurial repository and clone it unto the clients. For both existing and new repositories it is worth considering disallowing pushes directly to the 'upstream' repository.
In Jenkins each job can be configured to use Pretested Integration from the job configuration page. Once selected, Jenkins will start building the job in question every time a developer pushes change to the repository defined in the plugin setup page (the staging repository). Whether or not this repository already exist, it is important to click 'Make/update repository': if the repository does not exist it will be created at the given path and a repository hook will be added. If the repository already exists, the hook will be added. This repository hook is responsible for starting builds, why this step is important. Refer to the supplied screenshot for a visual example.
At this point client repositories should change their default configuration for push-requests to point to this 'downstream' repository.
Currently when using the 'Make/update repository' button, backslashes are removed from the hgrc file of the staging repository. Users should verify that their paths and other variables in the hgrc file are correct after using the button.
No changes yet.