Skip to content

Automation

Jump to bottom
Dan Ibanez edited this page Nov 14, 2016 · 5 revisions

Automation System

Our automation system attempts to balance multiple needs:

  1. Provide developers with minimal workflow restriction
  2. Ensure personal copies are merged to a central location
  3. Ensure users receive stable software
  4. Ensure our public and private versions are well coordinated

The software repository setup is as follows:

  1. Each repository has exactly two branches: master and develop.
  2. All developers can modify the develop branch at will, without restriction.
  3. No developer may directly modify the master branch.
  4. Every day, an automated process will perform regression tests on both branches, and post the results online here.
  5. Every day, an automated process will merge all changes from the develop branch to the master branch if and only if the resulting master regression tests pass.
  6. A select group of Owners may modify master for the limited purposes of repairing the automated system.

The following image illustrates the system:

AutoMerge

This system maintains substantial freedom:

  1. There is no barrier to pushing changes to develop, encouraging most work to be done directly in develop.
  2. Merges are automated, not manual, so there is no need to depend on someone's availability (or subjective judgement) to merge code.

The system also maintains high stability:

  1. It should be nearly impossible for the master branch(es) to fail regression tests at any time.
  2. The only way to get one individual's changes accepted into master is to ensure they are compatible with changes by other developers.
  3. The way to ensure the master branch behaves a certain way is to set up an automated regression test for it.

By default, most work should be pushed to develop. Forks and other branches can still be maintained for serious refactoring, with conscious awareness that each day a version remains separate decreases its probability of survival via merging.

How to Check

Developers should check this website on a daily basis:

http://my.cdash.org/index.php?project=SCOREC

It indicates the health of the master and develop branches as well as the health of the proposed merge of the two.

If it is not clear from this page why the merge was not accepted, please read this log file:

http://scorec.rpi.edu/~dibanez/nightly_cmake_log.txt

This file will indicate if issues such as warning count or merge conflicts are the cause of non-acceptance.

Clone this wiki locally