Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

Plugin Information

View Pretested Integration on the plugin site for more information.

Developed by

Alexander Winther Uldall
Ronni Elken Lindsgaard
Esben Skaarup
Andreas Frisch

This plugin lets Jenkin manage a repository – keeping it in a clean state by only integrating changesets which build successfully. Builds – and thus repository updates – are triggered when developers push to another designated repository.

Description

This plugin aims to prevent accidentally breaking a repository through dirty commits. Instead of pushing directly to the repository in question, the clients will push to another repository made especially for this task. Jenkins will be triggered and start a build every time a changeset is pushed to this repository. Each build will merge the given changeset into the latest working copy of the project and run the job. If – and only if – the merged changeset builds successfully we will commit this to the original repository.

The system defined in this plugin depends on three parts: An 'upstream' repository where developers can pull the latest stable version; a 'downstream' staging 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.

  • Upstream repository: This is the repository that you want Jenkins to manage in order to keep it in a working condition. This repository will usually be the original repository which clients pull from.
  • Staging repository: This repository is created by this plugin and is used by Jenkins to perform pretested integration. Clients will push their changesets to this repository to have them validated and - if they merge flawlessly with the current stable version and pass all tests - these changesets are integrated into the upstream repository.
  • Client repositories: These are the repositories on the client machines. The only changes required for these are to which repository they push changesets.

Limitations

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.

Setup

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 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 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 the [paths] section in the repository's .hg/hgrc file, this this:

[paths]
default-push = ssh://path/to/upstream/repository/

Known Issues

  • Validation of the staging repository setup is not thorough enough.
  • Client SCM settings should be autogenerated for ease of deployment.
  • 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.

Changes

No changes yet.

  • No labels