RETIRED, Puppet module to deploy an OpenStack ci system
Go to file
Ian Wienand fecd0ae3d8 Add dbus libs for "keyring" build
The keyring package has acquired dependencies on dbus-python so add
the packages required for build.  See also
4ce7759c103b45de84a2822e000fdc860b4bd6c3

Change-Id: I1a584cd3f86761d058cd0a128c1fee3c20f5502d
2016-06-27 13:33:13 +10:00
contrib Clarify oscc_file_contents instructions 2016-03-03 12:04:26 -08:00
doc/source Initiate nodepool-builder on third_party_ci.rst 2016-03-16 12:32:26 +00:00
files Match file conditions to apache rewrite rules 2015-10-08 10:39:52 -07:00
manifests Add dbus libs for "keyring" build 2016-06-27 13:33:13 +10:00
spec Use openstack-infra jenkins users public ssh key 2016-06-09 13:35:45 -04:00
templates Logs: serve .log and .sh files as text/plain 2016-06-15 10:48:27 -07: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 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
other-requirements.txt Add other-requirements.txt for bindep support 2016-06-22 13:00:26 -04: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.