| Task or Resource | Client | How provided now | Future |
|---|---|---|---|
| Release build binaries | L1 | Built by RM, available from SLAC filesystem | |
| User | SLAC filesystem for local users; Installer for remote users | ||
| Externals for a particular build | L1 | Available from SLAC filesystem | |
| SLAC user | SLAC filesystem | ||
| Remote user | Externals are stashed by RM and locations recorded in db. Installer looks them up | ||
| Source for a particular build | Superuser | Developer tar ball (created by RM as part of build) or check out from CVS by tag | Dev tarball if available. Also Repoman: invoke script subrepo: native git commands |
| Bleeding edge source | Developer | Check out or update from CVS | Repoman: invoke script subrepo: native git commands |
| Tag a package | Developer | Use stag program. (Note CVS tagger hook disallows certain tag operations by unprivileged users) | |
| Tag a container (release or release candidate) | Developer | User tagCollector python script. Requires presence of packageList.txt in container | |
| Tag a container (LATEST builds) | Continuous integration | RM daemon periodically invoked, searches repository for new package tags. | |
| Create publicly-available builds | Continuous integration | RM daemon periodically invoked, searches for new container tags | |
| Display build output, errors | Developers, users | RM II web pages display information stored in RM database during build process | |
| Notify developers of build errors | Developers | Part of RM build | |
| Commit code | Developer | CVS commit | Repoman: git push subrepo: git push; subrepo push |
The Clients, defined
L1 - needs no introduction
User - may be local to SLAC or remote. Runs ST or GR code but does not modify or develop
Superuser - same as user but may have reason to build from source, e.g. to support alternate platform
Developer - modifies or adds to code
Continuous integration - isn't really a client so much as a purpose. Developer and, to some extent, users are the real clients
Tagging
Currently the two kinds of tagging operations (tag a package or tag a container) involve more than just creating a tag in CVS. We need to decide how much of the current additional functionality should be carried over to the new system.
Package tag
Package tags are created by means of the stand-alone program stag. In addition to creating the tag, stag
- accepts options like -minor so that caller does not have to specify the three numeric components of the new tag
- updates the SConscript file to include the new version designation
- updates the file doc/release.notes belonging to the package so there is a concise record of changes to the package
[jrb@rhel6-64g eTraveler-clientAPI]$ stag -h stag version 0.2.5 Syntax for stag: stag -cvspath=path-rel-to-cvsroot -notes="text-for-release-notes" (-major | -minor | -patch | -custom=version-spec) [-branch=cvs-branch ] [-verbose] [-S] Options may appear in any order and may be abbreviated if unambiguous. -cvspath, -notes and one of the version specification options are required. The last component of cvspath identifies package tagged Specify -verbose option for additional informational output -S is used iff package contains SConstruct rather than SConscript (i.e., when tagging SConsFiles) Examples: stag -notes="Some comments" -patch -cvspath=xmlBase stag -notes="Tagging a subpackage" -minor -cvspath=celestialSources/GRB (tags package GRB) stag -notes="Tagging parent" -minor -cvspath=celestialSources (tags celestialSources but not GRB, genericSources, etc.) stag -notes="Tagging along a branch" -branch=GlastRelease-15-49-02 -custom=05-04-11-gr01 -cvspath=xmlBase