| 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.
...
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.