|
Userland Gate Mechanics
|
|
The userland consolidation operates a set of Mercurial repositories that work
|
together to manage the tools, source code, and build recipies. These
|
repositories are the integration repository, gate, and external mirror. This is
|
similiar to how the Solaris ON, SFW, and other gates operates, however there
|
are a few subtle differences. In ON and other consolidations, the integration
|
repository is that gate and contains the canonical source. Once a changeset
|
is committed, it becomes a part of the canonical source. In the case of ON,
|
the changeset is immediately pushed to the clone repository. SFW and other
|
consolidations push changes from their canonical gate to a clone repository
|
nightly. In the userland consolidation, developers will commit changes to the
|
integration gate. These changes will not be accepted until some basic
|
validation is performed. Once the validation completes successfully, the
|
changes are accepted and pushed into the canonical source gate.
|
|
Integration repository (ssh://ulhg@userland//nevada/incoming)
|
The integration gate is the Mercurial repository that all tools, source
|
code, and build recipies are committed to. Unlike ON, SFW, and other
|
Solaris gates this source code repository does not contains the canonical
|
source for the product. This repository is a staging area for change
|
integration and acceptance.
|
|
hg push to integration gate
|
|
|
v
|
lock gate
|
|
|
v
|
validate changeset(s) -> failed --> rollback changeset(s)
|
| |
|
v |
|
accepted |
|
| |
|
v v
|
push to clone -------------------> unlock gate
|
|
|
v
|
update bug db
|
|
|
v
|
notify committer
|
|
So, the basic flow works something like this: A user pushes a changeset
|
to the integration gate. Mercurial locks the gate to block any other
|
attempts to operate on the gate while it is validating the changeset.
|
At this point, validation is started in the background, a message is
|
displayed, and control is returned to the user. Validation continues
|
in the background. If validation completes successfully, the changeset(s)
|
are pushed to the clone, the gate is unlocked, the bug database is updated,
|
and the user is notified of the changeset acceptance. If the validation
|
fails, the changeset(s) are rolled back, the gate is unlocked, and the
|
user is notified of the failure.
|
|
Changeset validation will include the following:
|
multi-delta update check
|
commit comment validation
|
bugdb validation
|
future operations
|
source archive download
|
incremental build on all architectures
|
unit test on all architectures
|
package publication for all architectures
|
|
|
Canonical source repository (ssh://anon@userland//nevada/gate)
|
The clone gate is actually the mercurial repository that contains the
|
canonical tools, source code, and build recipies for the product. It
|
should always be in a stable, buildable state. When changes are pushed
|
to this gate, they are mirrored on the external mirror repository from
|
here.
|
|
clone update
|
|
|
v
|
push to external mirror
|
|
|
v
|
notify gatelings
|
|
|
External mirror repository (ssh://anon@hg.opensolaris.org//hg/userland/gate)
|
The external mirror is the mercurial repository that contains an externally
|
accessible copy of the canonical tools, source code, and build recipies for
|
the product. It should always be in a stable, buildable state.
|
|
external mirror update
|
|
|
v
|
notify gatelings
|
|
# vi:set fdm=marker expandtab ts=4:
|