opendev
/
puppet-openstackci
Code Issues Proposed changes
RETIRED, Puppet module to deploy an OpenStack ci system
167 Commits 1 Branch 0 Tags 2.6 MiB
Go to file
Clark Boylan 524d236b80 Set json.gz mimetype properly 
This sets the json.gz files' mimetype to application/json so that we can
compress stackviz report data and still have it render properly in your
browser. This will allow us to save space on the log server.

Change-Id: I42d7d607e5864a81d52e72ff695331eb2d67d2c0
 		2017-05-25 15:08:57 -07:00
contrib Pass Java arguments to Jenkins master 2017-03-28 10:41:38 +03:00
doc/source Remove link to modindex 2016-12-28 16:43:04 +01:00
files Reduce job log retention to 45 days 2017-02-15 21:21:43 +00:00
manifests Add libssl-dev for keyring package on logserver 2017-04-05 10:56:31 +10:00
spec Fix beaker-rspec tests for centos7 2017-04-13 22:37:52 +02:00
templates Set json.gz mimetype properly 2017-05-25 15:08:57 -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
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
bindep.txt Move other-requirements.txt to bindep.txt 2016-08-12 19:30:33 +02:00
metadata.json Use our custom pip provider for keyring package 2016-04-22 09:25:49 -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

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.