Go to file

Colleen Murphy d0ee5c2cf4 Add beaker tests for nodepool

Add tests for the nodepool launcher and builder. Since by default this
uses the nodepool configuration found in openstack-infra/project-config,
fudge the hostnames so that it can find a real config file.

Depends-On: https://review.openstack.org/577519
Change-Id: I036c1afc0414f846c9112ef5bc5f3abd486f3147

2018-08-14 13:03:40 +00:00

contrib

Add support for installing ARA wsgi middleware for sqlite databases

2018-03-05 15:08:40 -05:00

doc/source

Merge "added Single Use Slave plugin"

2017-06-05 15:27:06 +00:00

files

Allow viewing of .log.gz files

2018-02-12 10:05:15 +11:00

manifests

Merge "Fix puppet syntax for nodepool builder logic"

2018-05-21 03:58:28 +00:00

spec/acceptance

Add beaker tests for nodepool

2018-08-14 13:03:40 +00:00

templates

Fix template variables

2018-07-12 09:27:03 +02: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

Add beaker-rspec bindep dependencies

2018-06-28 08:13:31 +00:00

CONTRIBUTING.rst

Add a CONTRIBUTING.rst document

2016-01-07 17:34:58 -08:00

Gemfile

Update Gemfile for Zuulv3

2018-08-06 20:08:47 +00: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

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.