← Back to branch summary

~mark-mims/charms/oneiric/charmtester/trunk

« back to all changes in this revision

Viewing changes to README.markdown

  • Committer: Mark Mims
  • Date: 2012-03-22 23:25:57 UTC
  • Revision ID: mark.mims@canonical.com-20120322232557-l5thf2pvuwl89df6
play with formatting

Show diffs side-by-side

added added

removed removed

Lines of Context:
README.markdown
2
2
# The goal
3
3
 
4
4
Publish charm tests organized around:
 
5
 
5
6
  - series
6
7
  - provider
7
8
  - charm
8
9
  - other tags? (i.e., "main")
 
10
 
9
11
for each charm in the official charm store.
10
12
 
11
 
For each configured test environment (specifying {provider, series}), 
12
 
  For each charm in the official charm store,
13
 
    the charm tester will:
14
 
      - run charm-graph-tests
15
 
      - run charm unit-tests 
 
13
For each configured test environment (specifying {provider, series}) and each charm in the official charm store, the charm tester will:
 
14
 
 
15
  - run charm-graph-tests
 
16
  - run charm unit-tests 
16
17
 
17
18
 
18
19
# Components
19
20
 
20
21
- Jenkins
21
22
  - publish results
22
 
    - #juju
23
 
    - jenkins.qa.ubuntu.com
 
23
      - #juju
 
24
      - jenkins.qa.ubuntu.com
24
25
  - `API_TOKEN` to programmatically drive charmtesting
25
26
 
26
27
- charmtester (separate from and subordinate to jenkins... eventually)
27
28
  - creates(/removes?) jobs based on the current charm list
28
29
    one job per charm... `$series-$provider-charm-$charm_name`
29
30
  - each job
30
 
    - runs charm-graph-tests
31
 
    - runs charm unit-tests 
 
31
      - runs charm-graph-tests
 
32
      - runs charm unit-tests 
32
33
  - configured with environment(s) for this slave to test against
33
 
    - accts
34
 
    - providers
35
 
    - series
 
34
      - accts
 
35
      - providers
 
36
      - series
36
37
  - updates test components regularly(?)... juju, charms, plans
37
 
    - currently only on upgrade: (needs to be lighter-weight)
38
 
      - juju cli version
39
 
      - wipe/rebuild the master charmset regularly (this is used only to generate dependency graphs)
40
 
      - wipe/rebuild the lxc cache regularly for local provider
41
 
      - destroy and rebootstrap regularly to remove stale state (?)
 
38
      - currently only on upgrade: (needs to be lighter-weight)
 
39
          - juju cli version
 
40
          - wipe/rebuild the master charmset regularly (this is used only to generate dependency graphs)
 
41
          - wipe/rebuild the lxc cache regularly for local provider
 
42
          - destroy and rebootstrap regularly to remove stale state (?)
42
43
 
43
44
- charm test runner (curl with an `API_TOKEN` wrapped in a cronjob)
44
45
 
45
46
# Tests
46
47
 
47
48
- charm-graph-test
48
 
  - pulls a master charmset
49
 
  - generate test plans based on dep graphs (graph-test is the set of test plans for that charm)
50
 
  - job
51
 
    - pulls the charms for each run (separate from graph generation)
52
 
    - bootstraps
53
 
    - spins up each plan in the graph-test, watching for success/fail of each plan
 
49
    - pulls a master charmset
 
50
    - generate test plans based on dep graphs (graph-test is the set of test plans for that charm)
 
51
    - job
 
52
        - pulls the charms for each run (separate from graph generation)
 
53
        - bootstraps
 
54
        - spins up each plan in the graph-test, watching for success/fail of each plan
54
55
 
55
56
- charm-unit-test
56
 
  - just hit `$CHARM_DIR/tests/test` and run screaming?
57
 
  - maybe sandbox this a little
58
 
  - ?
 
57
    - just hit `$CHARM_DIR/tests/test` and run screaming?
 
58
    - maybe sandbox this a little
 
59
    - ?
59
60
 
60
61
# TODO
61
62
 
62
63
- update charmrunner to work against other providers (currently local-only)
63
64
 
64
65
- persist job stuff between instances (address backups _and_ availability)
65
 
  - S3?
 
66
    - S3?
66
67
 
67
68
- charmtester needs to:
68
 
  - use lighter-weight updates for test components
69
 
  - trigger by commit-hooks
70
 
  - only re-run charms that have diffs
71
 
  - handle deletions from the charm list
 
69
    - use lighter-weight updates for test components
 
70
    - trigger by commit-hooks
 
71
    - only re-run charms that have diffs
 
72
    - handle deletions from the charm list
72
73
 
73
74
- turn charmrunner into juju-jitsu plugins
74
75