|
1 |
|
2 Userland Gate Mechanics |
|
3 |
|
4 The userland consolidation operates a set of Mercurial repositories that work |
|
5 together to manage the tools, source code, and build recipies. These |
|
6 repositories are the integration repository, gate, and external mirror. This is |
|
7 similiar to how the Solaris ON, SFW, and other gates operates, however there |
|
8 are a few subtle differences. In ON and other consolidations, the integration |
|
9 repository is that gate and contains the canonical source. Once a changeset |
|
10 is committed, it becomes a part of the canonical source. In the case of ON, |
|
11 the changeset is immediately pushed to the clone repository. SFW and other |
|
12 consolidations push changes from their canonical gate to a clone repository |
|
13 nightly. In the userland consolidation, developers will commit changes to the |
|
14 integration gate. These changes will not be accepted until some basic |
|
15 validation is performed. Once the validation completes successfully, the |
|
16 changes are accepted and pushed into the canonical source gate. |
|
17 |
|
18 Integration repository (ssh://ulhg@userland//nevada/incoming) |
|
19 The integration gate is the Mercurial repository that all tools, source |
|
20 code, and build recipies are committed to. Unlike ON, SFW, and other |
|
21 Solaris gates this source code repository does not contains the canonical |
|
22 source for the product. This repository is a staging area for change |
|
23 integration and acceptance. |
|
24 |
|
25 hg push to integration gate |
|
26 | |
|
27 v |
|
28 lock gate |
|
29 | |
|
30 v |
|
31 validate changeset(s) -> failed --> rollback changeset(s) |
|
32 | | |
|
33 v | |
|
34 accepted | |
|
35 | | |
|
36 v v |
|
37 push to clone -------------------> unlock gate |
|
38 | |
|
39 v |
|
40 update bug db |
|
41 | |
|
42 v |
|
43 notify committer |
|
44 |
|
45 So, the basic flow works something like this: A user pushes a changeset |
|
46 to the integration gate. Mercurial locks the gate to block any other |
|
47 attempts to operate on the gate while it is validating the changeset. |
|
48 At this point, validation is started in the background, a message is |
|
49 displayed, and control is returned to the user. Validation continues |
|
50 in the background. If validation completes successfully, the changeset(s) |
|
51 are pushed to the clone, the gate is unlocked, the bug database is updated, |
|
52 and the user is notified of the changeset acceptance. If the validation |
|
53 fails, the changeset(s) are rolled back, the gate is unlocked, and the |
|
54 user is notified of the failure. |
|
55 |
|
56 Changeset validation will include the following: |
|
57 multi-delta update check |
|
58 commit comment validation |
|
59 bugdb validation |
|
60 future operations |
|
61 source archive download |
|
62 incremental build on all architectures |
|
63 unit test on all architectures |
|
64 package publication for all architectures |
|
65 |
|
66 |
|
67 Canonical source repository (ssh://anon@userland//nevada/gate) |
|
68 The clone gate is actually the mercurial repository that contains the |
|
69 canonical tools, source code, and build recipies for the product. It |
|
70 should always be in a stable, buildable state. When changes are pushed |
|
71 to this gate, they are mirrored on the external mirror repository from |
|
72 here. |
|
73 |
|
74 clone update |
|
75 | |
|
76 v |
|
77 push to external mirror |
|
78 | |
|
79 v |
|
80 notify gatelings |
|
81 |
|
82 |
|
83 External mirror repository (ssh://[email protected]//hg/userland/gate) |
|
84 The external mirror is the mercurial repository that contains an externally |
|
85 accessible copy of the canonical tools, source code, and build recipies for |
|
86 the product. It should always be in a stable, buildable state. |
|
87 |
|
88 external mirror update |
|
89 | |
|
90 v |
|
91 notify gatelings |
|
92 |
|
93 # vi:set fdm=marker expandtab ts=4: |