opendev
/
puppet-openstackci
Code Issues Proposed changes
RETIRED, Puppet module to deploy an OpenStack ci system
88 Commits 1 Branch 0 Tags 2.6 MiB
Go to file
Ramy Asselin b0949811ee Pin nodepool to latest tag 0.3.0 for 3rd party CI 
There are some upcoming changes to nodepool. [1]
Pin to 0.3.0 to keep 3rd party ci more stable.

[1] http://lists.openstack.org/pipermail/openstack-infra/2016-July/004526.html

Change-Id: I196507c84c822f4ed0243c968315610bd1a8c030
 		2016-07-08 07:23:34 -07:00
contrib Pin nodepool to latest tag 0.3.0 for 3rd party CI 2016-07-08 07:23:34 -07:00
doc/source Merge "Updated gearman default port information" 2016-01-24 17:54:52 +00:00
files Match file conditions to apache rewrite rules 2015-10-08 10:39:52 -07:00
manifests Merge "Add pass through for swift_account_temp_key" 2016-02-09 12:14:19 +00:00
spec Fix target path for regular git clone during tests 2015-08-19 10:39:23 +00:00
templates Prepopulate log server for single-node-ci 2015-11-20 09:48:39 -08:00
.gitignore Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
.gitreview Added .gitreview 2015-03-18 17:00:55 +00:00
CONTRIBUTING.rst Add a CONTRIBUTING.rst document 2016-01-07 17:34:58 -08:00
Gemfile Add Gemfile 2015-06-08 12:41:18 -07:00
LICENSE Initial files for the puppet-openstackci repo 2015-03-24 12:05:27 -07:00
README.md Add developer guidelines 2015-04-29 01:46:24 -07:00
Rakefile Initial files for the puppet-openstackci repo 2015-03-24 12:05:27 -07:00
metadata.json Add generic logstash manifests 2015-10-28 13:19:43 -05:00
setup.cfg Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
setup.py Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
test-requirements.txt Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
tox.ini Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00

README.md

OpenStack Continuous Integration Module

Overview

Configures an OpenStack Continuous Integration System

Developing

If you are adding features to this module, first ask yourself: "Does this logic belong in the module for the service?"

An example of this is the gearman-logging.conf file needed by the zuul service. This file should be managed by the zuul module, not managed here. What should go in this module is high level directives and integrations such as a list of jenkins plugins to install or a class that instantiates multiple services.