Versions Compared

Old Version 2

changes.mady.by.user Joanne Bogart

Saved on

compared with

New Version Current

changes.mady.by.user Joanne Bogart

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
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 buildSuperuser1Developer 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) Native git tag command. Likely also need tool to emulate some stag functions.
Tag a container (release or release candidate)DeveloperUser tagCollector python script.  Requires presence of packageList.txt in container 
Tag a container (LATEST builds)Continuous integration2RM daemon periodically invoked, searches repository for new package tags. 
Create publicly-available buildsContinuous integration2RM 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 including constituent package tags of a build, compile output, test program output, comparisons, etc. 
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 1Superuser is the same user but may have a reason to build from source, e.g. to support alternate platform

Developer - modifies or adds to code

run on a non-standard platform.

2Continuous integration is the purpose; the ultimate clients are developers.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.

...

  • 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
Code Block
languagebash
titlestag 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

Container tag

Currently container tags are created via the script tagCollector.py. 

 

From SCons Command Line Tag Collector:

Panel
borderColorGray
borderStyleSolid
titletagCollector functionality

tagCollector  handles these activities:

  1. Make a new release tag which is identical to current HEAD build
  2. Make a new HEAD, not based on any previous HEAD.
  3. Make a new HEAD by changing some package tags, adding new packages or removing packages as compared to current HEAD
  4. Make a new release tag along a branch. The only files which need to be on the branch are the top-level files packageList.txt, ChangeLog and, if it exists, containerNotes.txt.

There must be a file packageList.txt, listing all packages and versions belonging to the build at the top level (e.g. ScienceTools-scons/packageList.txt). It is used to determine what gets the new tag in cases 1., 2. and 4. above. For 3., tagCollector.py will update the packageList.txt belonging to the old HEAD appropriately .

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.