Juju CI (Go and Python)

Registered by Clint Byrum

Rational:
Juju is subject to a rapid development pace, and will continue to do so. We should gate both trunks (python and go) on unit and functional tests passing. This should include some form of the official charm tests. This will require substantial infrastructure to test all providers such as MaaS.

Goal:
A documented process that instructs Juju developers on how the tooling for Juju is accomplished.

Blueprint information

Status:
Not started
Approver:
Antonio Rosales
Priority:
High
Drafter:
Ubuntu Server
Direction:
Approved
Assignee:
Jim Baker
Definition:
Discussion
Series goal:
Accepted for raring
Implementation:
Deferred
Milestone target:
milestone icon ubuntu-13.04-beta-2

Related branches

Sprints

Whiteboard

## Feedback:
Jim / Clint: Can you add some WIs please?

- to jenkins or not to jenkins?
Current documentation on Charm testing:
  https://juju.ubuntu.com/docs/charm-tests.html

CI:
go team has unit/hybrid tests (David Cheney)
Goals:
user experience testing
on trunk
full set of functional tests (also have "live tests" core against the real provider)
five charms to test against
create dedicated test charms
how do we integrate providers?
WI:
charmtester on go asap
juju-functionality test charms
    -Charm on how to fully exercise Juju capabilities
    - repeatedly open-port/closes-port etc, or relation setting exercising with continuous handshaking
document repeating these tests
publicize embedded charm tests
test charms on demand for review (in addition to jitsu test from local env)
juju test docs move out of draft status
testrunner needs to be resilient against fixture failure
    -Have auto charm tester first check the health of the provider before doing follow on charm testing.
charmtester:
 mail juju-dev on break
 add unit tests as gate
 maintainer and/or file bug

--- User Stories ---

--- Risks ---

--- Test Plans ---

--- Release Note ---

--- Blog Post ---

(Need to sync up with the Juju Core team on their plans for Juju CI testing to properly spec this out.) -[a.rosales; 12-Dec-2012]

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.