Skip to content
Browse files
JENKINS-25888: More documentation - updated readme with few design de…
  • Loading branch information
buep committed Dec 4, 2014
1 parent fed47bb commit 547ed8fca5634c3380026f288a58162b7266cfba
Showing with 11 additions and 1 deletion.
  1. +11 −1
@@ -4,7 +4,10 @@ In this readme file you find _developer oriented documentation_, about contribut

_User oriented documentation_ is on the [Jenkins community wiki plugin page](

The [_roadmap_]( is a public Trello board.
The [_roadmap_]( is a public Trello board. Whil a simple bug, or very simple feature request just can be reported directly on the [Jenkins community issue tracker]( you should use the _roadmap_ for discussing new ideas, complicated features and the future of the plugin.

Current development efforts are also maintained Kanban-style on the Trello board.

The plugin is maintained in the scope of [Joint Open Source Roadmap Alliance (JOSRA)]( by [Praqma]( We happily accept pull request - see section about contributing below.

@@ -66,6 +69,9 @@ Concepts:
* **Ready** branches are specified by configuring the SCM plugin (not the prestested integration plugin) to pic up changes on those specific branches. For the Git plugin, it is the `Branch Specifier`.
* The **integration branch** is the target branch for integration. This is where changes from the ready-branches comes in.

Merge strategies:

**Accumulated** and **Squashed**. These are explained, together with more background information, and a discussion on the different merge strategies in [JOSRA]( as a blog post: " [Pretested Integration Plugin](".

## Architecture

@@ -98,6 +104,10 @@ Publish changes on success:

_We currently miss documentation on a lot of the design decisions - they should go into this document._

## Only one integration repository is supported

* **Integration only support one repository**: Doing pretested integration on several repositories as the same time would not make sense conceptually. There should also be a 1:1 relation between a Jenkins job and a repository as a best practice. Further it would not be possible to make pretested integration as an atomic non interuptable operation on several repositories. For example if they both integrate successfully, but publishing result fails on the second one. What should then happen with the first one?

## Logging

Our strategy for logging in the plugin is to:

0 comments on commit 547ed8f

Please sign in to comment.