~nskaggs/juju-ci-tools/add-assess-terms : contents of README.md at revision 1930

~nskaggs/juju-ci-tools/add-assess-terms : (revision 1930)

# Continuous Integration scripts

The Juju QA team uses a common set or tests that exercise the release tools
and juju to verify that each revision of juju can be released, built, packaged,
published, installed, bootstrapped, and deployed.

CI requires
    lp:juju-release-tools (The packaging and publication tools)
    lp:juju-ci-tools (This branch)
    lp:juju-ci-tools/repository (A copy of the juju charm repository)
    And a JUJU_HOME with all the envs to test.

The general process involves making a release tarball, making a package,
making a tree of tools and metadata, and lastly publishing the tools.
you can skip the tarball and package steps if you just want to publish
the juju tools (AKA jujud, servers, agents). If you want to test a fix
that is in the juju-core trunk branch, you can make your own release
tarball and package.

Once juju is published to the test clouds, individual tests can be performed.
Most tests accept an env name. The envs define the cloud and series to test.

## Requirements for running tests
You will need some python libraries in order to run the existing CI tests.
Install the following

sudo apt-get install python-launchpadlib python-yaml python-boto python-mock
 python-jenkins python-novaclient python-pexpect python-winrm python-coverage

In addition, if you wish to use azure, you will need to install pip, and the
associated client library from pip for azure.

sudo apt-get install python-pip
pip install azure

# Creating a New CI Test

Test scripts will be run under many conditions to reproduce real cases.
Most scripts cannot assume special knowledge of the substrate, region,
bootstrap constraints, tear down, and log collection, etc.

If this is your first time, consider asking one of the QA team to pair-program
on it with you.

You can base your new script and its unit tests on the template files.
They provide the infrastructure to setup and tear down a test. Your script
can focus on the unique aspects of your test. Start by making a copy of
template_assess.py.tmpl, and don't forget unit tests!

    make new-assess name=my_function

Run make lint early and often. (You may need to do sudo apt-get install python-
flake8). If you forget, you can run autopep8 to fix certain issues. Please use
--ignore E24,E226,E123 with autopep8. Code that's been hand-written to follow
PEP8 is generally more readable than code which has been automatically
reformatted after the fact. By running make lint often, you'll absorb the style
and write nice PEP8-compliant code.

Please avoid creating diffs longer than 400 lines. If you are writing a new
test, that may mean creating it as a series of branches. You may find bzr-
pipeline to be a useful tool for managing a series of branches.

If your tests require new charms, please write them in Python.

475 by Curtis Hovey Remove old information about scripts that were removed.	1	# Continuous Integration scripts
	2
	3	The Juju QA team uses a common set or tests that exercise the release tools
	4	and juju to verify that each revision of juju can be released, built, packaged,
	5	published, installed, bootstrapped, and deployed.
	6
	7	CI requires
476 by Curtis Hovey Update the location of all the resources needed for testing.	8	lp:juju-release-tools (The packaging and publication tools)
	9	lp:juju-ci-tools (This branch)
	10	lp:juju-ci-tools/repository (A copy of the juju charm repository)
	11	And a JUJU_HOME with all the envs to test.
94 by Curtis Hovey Added a readme to explain the scripts that non QA staff can use.	12
	13	The general process involves making a release tarball, making a package,
	14	making a tree of tools and metadata, and lastly publishing the tools.
	15	you can skip the tarball and package steps if you just want to publish
	16	the juju tools (AKA jujud, servers, agents). If you want to test a fix
	17	that is in the juju-core trunk branch, you can make your own release
	18	tarball and package.
	19
475 by Curtis Hovey Remove old information about scripts that were removed.	20	Once juju is published to the test clouds, individual tests can be performed.
	21	Most tests accept an env name. The envs define the cloud and series to test.
	22
1449.3.1 by Nicholas Skaggs quick partial fix for 1587926; add dependencies to readme so they are evident for users attempting to run tests	23	## Requirements for running tests
	24	You will need some python libraries in order to run the existing CI tests.
	25	Install the following
	26
	27	sudo apt-get install python-launchpadlib python-yaml python-boto python-mock
	28	python-jenkins python-novaclient python-pexpect python-winrm python-coverage
	29
	30	In addition, if you wish to use azure, you will need to install pip, and the
	31	associated client library from pip for azure.
	32
	33	sudo apt-get install python-pip
	34	pip install azure
1258.2.1 by Curtis Hovey Added section about creating new tests.	35
	36	# Creating a New CI Test
	37
	38	Test scripts will be run under many conditions to reproduce real cases.
	39	Most scripts cannot assume special knowledge of the substrate, region,
	40	bootstrap constraints, tear down, and log collection, etc.
1449.3.1 by Nicholas Skaggs quick partial fix for 1587926; add dependencies to readme so they are evident for users attempting to run tests	41
1258.2.1 by Curtis Hovey Added section about creating new tests.	42	If this is your first time, consider asking one of the QA team to pair-program
	43	on it with you.
	44
	45	You can base your new script and its unit tests on the template files.
	46	They provide the infrastructure to setup and tear down a test. Your script
	47	can focus on the unique aspects of your test. Start by making a copy of
	48	template_assess.py.tmpl, and don't forget unit tests!
	49
1258.2.3 by Curtis Hovey Fixed file names.	50	make new-assess name=my_function
1258.2.2 by Curtis Hovey Added assess_update_mongo tests.	51
1258.2.1 by Curtis Hovey Added section about creating new tests.	52	Run make lint early and often. (You may need to do sudo apt-get install python-
	53	flake8). If you forget, you can run autopep8 to fix certain issues. Please use
	54	--ignore E24,E226,E123 with autopep8. Code that's been hand-written to follow
	55	PEP8 is generally more readable than code which has been automatically
	56	reformatted after the fact. By running make lint often, you'll absorb the style
	57	and write nice PEP8-compliant code.
	58
	59	Please avoid creating diffs longer than 400 lines. If you are writing a new
	60	test, that may mean creating it as a series of branches. You may find bzr-
	61	pipeline to be a useful tool for managing a series of branches.
	62
1258.2.11 by Curtis Hovey Fix file ending.	63	If your tests require new charms, please write them in Python.