RETIRED, Puppet module to deploy an OpenStack ci system
Go to file
Paul Belanger 98e18bfc83 Add support for nodepool-launcher
This is part of our feature/zuulv3 effort to scale up our
nodepool-launcher process.

Change-Id: I29e661e38e9a2a56a01a1c30f1dc1eae97a4de7b
Depends-On: I393fa1d8ff080260af772a2f020cca9b9e49b173
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
2017-02-14 11:58:09 -05:00
contrib Update zuul & nodepool 3rd party ci pins to 2.5.1 & 0.3.1 2016-12-19 16:21:33 -08:00
doc/source Add a hint of project-config repository 2016-11-10 10:46:50 +09:00
files Reduce job log retention to 60 days 2016-09-29 15:53:41 +00:00
manifests Add support for nodepool-launcher 2017-02-14 11:58:09 -05:00
spec Use openstack-infra jenkins users public ssh key 2016-06-09 13:35:45 -04:00
templates Improve handling of gzipped built html/web applications 2016-11-15 09:31:39 -05: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
bindep.txt Move other-requirements.txt to bindep.txt 2016-08-12 19:30:33 +02:00
CONTRIBUTING.rst Add a CONTRIBUTING.rst document 2016-01-07 17:34:58 -08:00
Gemfile Use new infra_spec_helper for gem dependencies 2016-06-21 17:57:36 -07:00
LICENSE Initial files for the puppet-openstackci repo 2015-03-24 12:05:27 -07:00
metadata.json Use our custom pip provider for keyring package 2016-04-22 09:25:49 -07:00
Rakefile 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
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

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.