In order to get started using Pretested Integration, you need the three repositories described above: . The upstream and local repositories probably already exist. Otherwise, you must set up a remote Mercurial repository and clone it unto onto the clients. For both existing and new repositories it is worth considering disallowing pushes directly to the upstream repository. If this plugin is applied to an existing project, the remote repository from the Jenkins job settings will be used as upstream repository. Please remember that only Mercurial is currently supported.
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 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 simply 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 staging repository. In Mercurial, this is done by adding a
default-push parameter under
paths in the repository's
.hg/hgrc file, this this:
[paths] default-push = ssh://path/to/upstream/repository/
- Validation of the staging repository setup is not thorough enough.
- Client SCM settings should be autogenerated for ease of deploymentMultiple simultaneous (or close to simultaenous) pushes sometimes does not trigger.
- When two commits to the stage repository are made within a very short time interval, Jenkins will only trigger a single build instead of two.
No changes yet.