| 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 | Super UserSuperuser | Developer tar ball (created by RM as part of build) or check out from CVS by tag | Dev tarball if available. Also Repoman: Invoke for particular tag? invoke script subrepo: Clone or update from git, checkout tag native git commands |
| Bleeding edge source | Developer | Check out or update from CVS | Repoman: Invoke for HEAD? invoke script subrepo: Clone or update from 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
...
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
[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 |