Juju CI (Go and Python)
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:
-
ubuntu-13.04-beta-2
- Started by
- Completed by
Whiteboard
## Feedback:
Jim / Clint: Can you add some WIs please?
- to jenkins or not to jenkins?
Current documentation on Charm testing:
https:/
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/
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.
