You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Task or ResourceClientHow provided nowFuture
Release build binariesL1Built by RM, available from SLAC filesystem 
 UserSLAC filesystem for local users; Installer for remote users 
Externals for a particular buildL1Available from SLAC filesystem 
 SLAC userSLAC filesystem 
 Remote userExternals are stashed by RM and locations recorded in db. Installer looks them up 
Source for a particular buildSuperuserDeveloper 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 sourceDeveloperCheck out or update from CVS

Repoman: invoke script

subrepo: native git commands

Tag a packageDeveloperUse stag program. (Note CVS tagger hook disallows certain tag operations by unprivileged users) 
Tag a container (release or release candidate)DeveloperUser tagCollector python script.  Requires presence of packageList.txt in container 
Tag a container (LATEST builds)Continuous integrationRM daemon periodically invoked, searches repository for new package tags. 
Create publicly-available buildsContinuous integrationRM daemon periodically invoked, searches for new container tags 
Display build output, errorsDevelopers, usersRM II web pages display information stored in RM database during build process 
Notify developers of build errorsDevelopersPart of RM build 
Commit codeDeveloperCVS 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
stag help
[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 

 

 

 

  • No labels