| 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 | Superuser1 | 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) | Native git tag command. Likely also need tool to emulate some stag functions. |
| 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 integration2 | RM daemon periodically invoked, searches repository for new package tags. | |
| Create publicly-available builds | Continuous integration2 | 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 including constituent package tags of a build, compile output, test program output, comparisons, etc. | |
| Notify developers of build errors | Developers | Part of RM build | |
| Commit code | Developer | CVS commit | Repoman: git push subrepo: git push; subrepo push |
1Superuser is the same user but may have a reason to build from source, e.g. to run on a non-standard platform.
2Continuous integration is the purpose; the ultimate clients are developers.
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 by tag
[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
Container tag
Currently container tags are created via the script tagCollector.py. From SCons Command Line Tag Collector:
We will need some kind of tool to provide these functions, including keeping consistency between packageList.txt and the contents of the new tag, but most likely it can be simpler than tagCollector.py, which had to make allowances for poor CVS performance among other things.