opendev/infra-manual
Code Issues Proposed changes

Initial commit

Browse Source 
Change-Id: I27db4e65ae3b3d540a0f79831245ebc04fe8dac0
This commit is contained in:
James E. Blair 2014-05-06 17:46:09 -04:00 committed by Anita Kuno
parent bc993dfc1c
commit 4889eee82f
13 changed files with 855 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
LICENSE Normal file
View File

@ -0,0 +1,3 @@
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

9
README.rst Normal file
View File

@ -0,0 +1,9 @@
=======================================
OpenStack Project Infrastructure Manual
=======================================
To build the manual, execute the following command::
$ tox
After running ``tox``, the documentation will be available for viewing
in HTML format in the ``doc/build/`` directory.

BIN
doc/source/code_review.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 79 KiB

268
doc/source/conf.py Normal file
View File

@ -0,0 +1,268 @@
# -*- coding: utf-8 -*-
#
# Tempest documentation build configuration file, created by
# sphinx-quickstart on Tue May 21 17:43:32 2013.
#
# This file is execfile()d with the current directory set to its containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#sys.path.insert(0, os.path.abspath('.'))
# -- General configuration -----------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = ['sphinx.ext.autodoc',
'sphinx.ext.intersphinx',
'sphinx.ext.todo',
'sphinx.ext.viewcode',
'oslosphinx'
]
todo_include_todos = True
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'OpenStack Project Infrastructure Manual'
copyright = u'2014, OpenStack Contributors'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ['_build']
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
add_module_names = False
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
modindex_common_prefix = ['infra-manual.']
# -- Options for man page output ----------------------------------------------
man_pages = []
# -- Options for HTML output ---------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'nature'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
git_cmd = "git log --pretty=format:'%ad, commit %h' --date=local -n1"
html_last_updated_fmt = os.popen(git_cmd).read()
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
html_domain_indices = False
# If false, no index is generated.
html_use_index = False
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'Infra-Manualdoc'
# -- Options for LaTeX output --------------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass [howto/manual]).
latex_documents = [
('index', 'Infra-manual.tex', u'Infra Manual',
u'OpenStack Contributors', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for Texinfo output ------------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'Infra-manual', u'Infra Manual',
u'OpenStack Contributors', 'infra-manual', 'OpenStack Project Infrastructure Manual.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# -- Options for Epub output ---------------------------------------------------
# Bibliographic Dublin Core info.
epub_title = u'OpenStack Project Infrastructure Manual'
epub_author = u'OpenStack Contributors'
epub_publisher = u'OpenStack Contributors'
epub_copyright = u'2014, OpenStack Contributors'
# The language of the text. It defaults to the language option
# or en if the language is not set.
#epub_language = ''
# The scheme of the identifier. Typical schemes are ISBN or URL.
#epub_scheme = ''
# The unique identifier of the text. This can be a ISBN number
# or the project homepage.
#epub_identifier = ''
# A unique identification for the text.
#epub_uid = ''
# A tuple containing the cover image and cover page html template filenames.
#epub_cover = ()
# HTML files that should be inserted before the pages created by sphinx.
# The format is a list of tuples containing the path and title.
#epub_pre_files = []
# HTML files shat should be inserted after the pages created by sphinx.
# The format is a list of tuples containing the path and title.
#epub_post_files = []
# A list of files that should not be packed into the epub file.
#epub_exclude_files = []
# The depth of the table of contents in toc.ncx.
#epub_tocdepth = 3
# Allow duplicate toc entries.
#epub_tocdup = True

19
doc/source/core.rst Normal file
View File

@ -0,0 +1,19 @@
:title: Core Reviewer's Guide
.. _core_manual:
Core Reviewer's Guide
#####################
Maintaining the Core Group
==========================
+/-2 votes
==========
Approval
========
Re-approval
===========

401
doc/source/developers.rst Normal file
View File

@ -0,0 +1,401 @@
:title: Developer's Guide
.. _developer_manual:
Developer's Guide
#################
Quick Reference
===============
.. image:: code_review.png
Getting Started
===============
Account Setup
-------------
You'll need a `Launchpad account <https://launchpad.net/+login>`_,
since this is how the Web interface for the Gerrit Code Review system
will identify you. This is also useful for automatically crediting bug
fixes to you when you address them with your code commits.
If you haven't already, `join The OpenStack Foundation
<https://www.openstack.org/join/>`_ (it's free and required for all
code contributors). Among other privileges, this also allows you to
vote in elections and run for elected positions within The OpenStack
Project. When signing up for Foundation Membership, make sure to give
the same email address you'll use for code contributions, since this
will need to match your preferred email address in Gerrit.
Visit https://review.openstack.org/ and click the ``Sign In`` link at
the top-right corner of the page. Log in with your Launchpad ID.
Because Gerrit uses Launchpad OpenID single sign-on, you won't need a
separate password for Gerrit, and once you log in to one of Launchpad,
Gerrit, or any number of other OpenStack services, you won't have to
enter your password for the others.
Unless you are an U.S. Government Employee (see below), `agree to the
Individual Contributor License Agreement
<https://review.openstack.org/#/settings/agreements>`_ and provide
contact information. Your full name and email address will be public
(since they also appear in project commit logs) and the latter needs
to match the user.email in your Git configuration. The other contact
information (postal address, phone numbers) will be kept confidential
and is only used as a fallback record in the unlikely event The
OpenStack Foundation needs to reach you directly over code
contribution related matters. This contact information can also be
easily `updated <https://review.openstack.org/#/settings/contact>`_
later if desired, but make sure the primary email address always
matches the one you set for your OpenStack Foundation Membership --
otherwise Gerrit will give you an error message and refuse to accept
your contact information.
Employees of the the U.S. Government do not sign the Individual
CLA. Instead, someone with authority to sign on behalf of your agency
should sign the `U.S. Government Contributor License Agreement
<https://wiki.openstack.org/wiki/GovernmentCLA>`_. Please contact the
OpenStack Foundation to initiate this process.
If you are ``contributing on behalf of a company`` or organization,
you still need to sign the ICLA above but someone at your company or
organization also needs to sign the `Corporate Contributor License
Agreement <https://review.openstack.org/#/settings/agreements>`_
providing a list of people authorized to commit code to
OpenStack. Check `How to update the CCLA
<https://wiki.openstack.org/wiki/HowToUpdateCorporateCLA>`_ to provide
changes to such list. A list of current companies and organizations
with an existing `Corporate CLA
<https://wiki.openstack.org/wiki/Contributors/Corporate>`_ is available
for your review.
You'll also want to `upload an SSH key
<https://review.openstack.org/#/settings/ssh-keys>`_ while you're at
it, so that you'll be able to commit changes for review later.
Ensure that you have run these steps to let git know about your email
address::
git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"
To check your git configuration::
git config --list
Installing git-review
---------------------
We recommend using the ``git-review`` tool which is a git subcommand
that handles all the details of working with Gerrit, the code review
system used in OpenStack development. Before you start work, make
sure you have git-review installed on your system.
On Ubuntu Precise (12.04) and later, git-review is included in the
distribution, so install it as any other package::
apt-get install git-review
On Fedora 16 and later, git-review is included into the distribution,
so install it as any other package::
yum install git-review
On Red Hat Enterprise Linux, you must first enable the `EPEL
<http://fedoraproject.org/wiki/EPEL>`_ repository, then install it as
any other package::
yum install git-review
On openSUSE 12.2 and later, git-review is included in the distribution
under the name python-git-review, so install it as any other package::
zypper in python-git-review
On MacOSx, or most other Unix-like systems, you may install it with
pip::
pip install git-review
All of git-review's interactions with gerrit are sequences of normal
git commands. If you want to know more about what it's doing, just
add -v to the options and it will print out all of the commands it's
running.
Starting Work on a New Project
------------------------------
Clone a project in the usual way, for example::
git clone https://git.openstack.org/openstack/nova.git
You may want to ask git-review to configure your project to know about
Gerrit at this point. If you don't, it will do so the first time you
submit a change for review, but you probably want to do this ahead of
time so the Gerrit Change-Id commit hook gets installed. To do so
(again, using Nova as an example)::
cd nova
git review -s
Git-review checks that you can log in to gerrit with your ssh key. It
assumes that your gerrit/launchpad user name is the same as the
current running user. If that doesn't work, it asks for your
gerrit/launchpad user name. You can avoid that question by
configuring your Gerrit username, as follows::
git config --global gitreview.username yourgerritusername
If you don't remember your Gerrit user name go to the `settings page
on gerrit <https://review.openstack.org/#/settings/>`_ to check it out
(it's not your email address).
Note that you can verify the SSH host keys for review.openstack.org
here: https://review.openstack.org/#/settings/ssh-keys
Development Workflow
====================
Working on Bugs
---------------
TODO: Finding a bug in launchpad and assigning it to yourself.
Working on Blueprints
---------------------
TODO: Spec process.
Starting a Change
-----------------
Once your local repository is set up as above, you must use the
following workflow.
Make sure you have the latest upstream changes::
git remote update
git checkout master
git pull --ff-only origin master
Create a `topic branch
<http://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches>`_
to hold your work and switch to it. If you are working on a
blueprint, name your topic branch ``bp/BLUEPRINT`` where BLUEPRINT is
the name of a blueprint in launchpad (for example,
``bp/authentication``). The general convention when working on bugs
is to name the branch ``bug/BUG-NUMBER`` (for example,
``bug/1234567``). Otherwise, give it a meaningful name because it will
show up as the topic for your change in Gerrit::
git checkout -b TOPIC-BRANCH
Committing a Change
-------------------
`Git commit messages
<https://wiki.openstack.org/wiki/GitCommitMessages>`_ should start
with a short 50 character or less summary in a single paragraph. The
following paragraph(s) should explain the change in more detail.
If your changes addresses a blueprint or a bug, be sure to mention them in the commit message using the following syntax::
Implements: blueprint BLUEPRINT
Closes-Bug: ####### (Partial-Bug or Related-Bug are options)
For example::
Adds keystone support
...Long multiline description of the change...
Implements: blueprint authentication
Closes-Bug: #123456
Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657
Note that in most cases the Change-Id line should be automatically
added by a Gerrit commit hook installed by git-review. If you already
made the commit and the Change-Id was not added, do the Gerrit setup
step and run: ``git commit --amend``. The commit hook will
automatically add the Change-Id when you finish amending the commit
message, even if you don't actually make any changes.
Make your changes, commit them, and submit them for review::
git commit -a
Caution: Do not check in changes on your master branch. Doing so will
cause merge commits when you pull new upstream changes, and merge
commits will not be accepted by Gerrit.
Submitting a Change for Review
------------------------------
Once you have committed a change to your local repository, all you
need to do to send it to Gerrit for code review is run::
git review
When that completes, automated tests will run on your change and other
developers will peer review it.
Updating a Change
-----------------
If the code review process suggests additional changes, make and amend
the changes to the the existing commit. Leave the existing Change-Id:
footer in the commit message as-is. Gerrit knows that this is an
updated patch for an existing change::
git commit -a --amend
git review
Squashing Changes
-----------------
If you have made many small commits, you should squash them so that
they do not show up in the public repository. Remember: each commit
becomes a change in Gerrit, and must be approved separately. If you
are making one "change" to the project, squash your many "checkpoint"
commits into one commit for public consumption. Here's how::
git checkout master
git pull origin master
git checkout TOPIC-BRANCH
git rebase -i master
Use the editor to squash any commits that should not appear in the
public history. If you want one change to be submitted to Gerrit, you
should only have one "pick" line at the end of this process. After
completing this, you can prepare your public commit message(s) in your
editor. You start with the commit message from the commit that you
picked, and it should have a Change-Id line in the message. Be sure to
leave that Change-Id line in place when editing.
Once the commit history in your branch looks correct, run git review
to submit your changes to Gerrit.
Adding a Dependency
-------------------
When you want to start new work that is based on the commit under the
review, you can add the commit as a dependency.
Fetch change under review and check out branch based on that change::
git review -d $PARENT_CHANGE_NUMBER
git checkout -b $DEV_TOPIC_BRANCH
Edit files, add files to git::
git commit -a
git review
NOTE: git review rebases the existing change (the dependency) and the
new commit if there is a conflict against the branch they are being
proposed to. Typically this is desired behavior as merging cannot
happen until these conflicts are resolved. If you don't want to deal
with new patchsets in the existing change immediately you can pass
the -R option to git review in the last step above to prevent
rebasing. This requires future rebasing to resolve conflicts.
If the commit your work depends on is updated, and you need to get the
latest patch from the depended commit, you can do the following.
Fetch and checkout the parent change::
git review -d $PARENT_CHANGE_NUMBER
Cherry-pick your commit on top of it::
git review -x $CHILD_CHANGE_NUMBER
Submit rebased change for review::
git review
The note for the previous example applies here as well. Typically you
want the rebase behavior in git review. If you would rather postpone
resolving merge conflicts you can use git review -R as the last step
above.
Code Review
===========
Log in to https://review.openstack.org/ to see proposed changes, and
review them.
To provide a review for a proposed change in the Gerrit UI, click on
the Review button (it will be next to the buttons that will provide
unified or side-by-side diffs in the browser). In the code review, you
can add a message, as well as a vote (+1,0,-1).
Any Openstack developer may propose or comment on a change (including
voting +1/0/-1 on it). Openstack projects have a policy requiring two
positive reviews from core reviewers. A vote of +2 is allowed from
core reviewers, and should be used to indicate that they are a core
reviewer and are leaving a vote that should be counted as such.
When a review has two +2 reviews and one of the core team believes it
is ready to be merged, he or she should leave a +1 vote in the
"Approved" category. You may do so by clicking the "Review" button
again, with or without changing your code review vote and optionally
leaving a comment. When a +1 Approved review is received, Jenkins will
run tests on the change, and if they pass, it will be merged.
A green checkmark indicates that the review has met the requirement
for that category. Under "Code-Review", only one +2 gets the green
check.
Automated Testing
-----------------
When a new patchset is uploaded to Gerrit, that project's "check"
tests are run on the patchset by Jenkins. Once completed the test
results are reported to Gerrit by Jenkins in the form of a Verified:
+/-1 vote. After code reviews have been completed and a change
receives an Approved: +1 vote that project's "gate" tests are run on
the change by Jenkins. Jenkins reports the results of these tests back
to Gerrit in the form of a Verified: +/-2 vote. Code merging will only
occur after the gate tests have passed successfully and received a
Verified: +2. You can view the state of tests currently being run on
the Zuul Status.
If a change fails tests in Jenkins, please follow the steps below:
1. Jenkins leaves a comment in the review with links to the log files for the test run. Follow those links and examine the output from the test. It will include a console log, and in the case of unit tests, HTML output from the test runner, or in the case of a devstack-gate test, it may contain quite a large number of system logs.
2. Examine the console log or other relevant log files to determine the cause of the error. If it is related to your change, you should fix the problem and upload a new patchset. Do not use "recheck" or "reverify".
3. If the problem is due to non-deterministic behavior already merged, and is unrelated to your change, you should do the following to help other developers who may be affected by the same issue, and to focus attention of QA, CI, and other developers working to fix high-impact bugs and improve test systems:
1. Visit http://status.openstack.org/rechecks/ to see if one of the bugs listed there matches the error you've seen. If your error isn't there, then:
2. Identify which project(s) are affected, and search for a related bug on Launchpad. If you do not find an existing bug, file a new one (and be sure to include the error message). If the problem is due to an infrastructure problem (such as Jenkins, Gerrit, etc.), file (or search for) the bug against the openstack-ci project.
4. To update the rechecks status page to help others prioritize fixes for transient issues, leave a comment on the review referencing the bug causing the transient failure (not the bug you're attempting to fix with your patch):
1. To re-run the check jobs (before a change has been approved), leave a comment with the form "recheck bug ####".
2. To re-run the gate jobs (after a change has been approved), leave a comment with the form "reverify bug ####".
5. If a nice message from Elastic Recheck didn't show up in your patch when Jenkins failed, and you've identified a bug to recheck/reverify against, help out by writing an elastic-recheck query for the bug.
If you need to re-run tests and it does not make sense to include a bug number (perhaps there is no error, you've just made a draft change visible and want it tested or you're updating test results because you know that a related branch has changed since the last time they were run), you may leave a comment with the form "recheck no bug". Please only do this if you are certain there is no bug that needs to be addressed. A bug number is required to reverify.
Peer Review
-----------
https://wiki.openstack.org/wiki/ReviewChecklist
Work in Progress
----------------
TODO
Merging
=======
TODO
Project Gating
--------------
TODO

46
doc/source/drivers.rst Normal file
View File

@ -0,0 +1,46 @@
:title: Project Driver's Guide
.. _driver_manual:
Project Driver's Guide
######################
Feature Branches
================
Merge Commits
-------------
Release Management
==================
Milestones
----------
Create milestone-proposed Branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Authoring Changes for milestone-proposed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Submit Changes in master to milestone-proposed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Submit Changes in milestone-proposed to master
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tagging a Release
~~~~~~~~~~~~~~~~~
End of Milestone
~~~~~~~~~~~~~~~~
Targeting Blueprints
====================
Gerrit IRC Notifications
========================
Running Jobs with Zuul
======================

22
doc/source/index.rst Normal file
View File

@ -0,0 +1,22 @@
:title: OpenStack Project Infrastructure User Manual
.. _infra_manual:
Infrastructure User Manual
##########################
The OpenStack project uses a number of specialized tools and processes
while developing software that is part of the project. This manual
will help you learn how to use them as a developer working on the
OpenStack project.
If you are not trying to contribute to OpenStack directly, but are
instead a user or developer looking for API documentation, see
`OpenStack documentation <http://docs.openstack.org>`_.
.. toctree::
:maxdepth: 2
developers
core
drivers

22
doc/source/notes Normal file
View File

@ -0,0 +1,22 @@
Core Reviewers:
Maintaining the Core Group
+/-2 votes
Approval
Re-approval
Project Drivers:
Feature Branches
Merge Commits
Release Management
Milestones
Create milestone-proposed Branch
Authoring Changes for milestone-proposed
Submit Changes in master to milestone-proposed
Submit Changes in milestone-proposed to master
Tagging a Release
End of Milestone
Targeting Blueprints
Gerrit IRC Notifications
Running Jobs with Zuul

4
requirements.txt Normal file
View File

@ -0,0 +1,4 @@
pbr>=0.6,<1.0
docutils==0.9.1
oslosphinx
sphinx>=1.1.2,<1.2

23
setup.cfg Normal file
View File

@ -0,0 +1,23 @@
[metadata]
name = infra-manual
summary = OpenStack Project Infrastructure Manual
description-file =
README.rst
author = OpenStack
author-email = openstack-infra@lists.openstack.org
home-page = http://www.openstack.org/
classifier =
Intended Audience :: Developers
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
[build_sphinx]
all_files = 1
build-dir = doc/build
source-dir = doc/source
[pbr]
warnerrors = True
[wheel]
universal = 1

21
setup.py Executable file
View File

@ -0,0 +1,21 @@
#!/usr/bin/env python
# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
# implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import setuptools
setuptools.setup(
setup_requires=['pbr'],
pbr=True)

17
tox.ini Normal file
View File

@ -0,0 +1,17 @@
[tox]
minversion = 1.6
envlist = docs
skipsdist = True
[testenv]
usedevelop = True
setenv = VIRTUAL_ENV={envdir}
install_command = pip install -U {opts} {packages}
deps = -r{toxinidir}/requirements.txt
commands = python setup.py testr --slowest --testr-args='{posargs}'
[testenv:venv]
commands = {posargs}
[testenv:docs]
commands = python setup.py build_sphinx