Changes between Version 18 and Version 19 of NuWa_Slave

Timestamp:

09/17/10 17:06:32 (15 years ago)

Author:

blyth (IP: 140.112.102.77)

Comment:

--

NuWa_Slave

@@ -464 +464 @@
 2 lists of hostnames for "opt.dybinst" and "dybinst" builds.
  
-The '''copy''' step of the '''opt''' builds copies to : {{{ <dyb_copybase>/opt/Nuwa-<revision> }}} 
-rather than the normal : {{{<dyb_copybase>/NuWa-<revision>}}} where '''dyb_copybase''' is configured in 
-for examples '''~/.dybinstrc''' .
-  * not configuring it prevents the copy from being done
+
 
 
@@ -481 +478 @@
  
 
-= ''dybbin'' Approach Under Discussion =
-
-
-  * '''dybbin''' allows a NuWa installation to be copied to another location
-
-== email to David, Jiajie ==
-
-{{{
- I like the elimination of a separate build in this dybbin
- approach however I see several problems with usage of update builds
- and externally imposed cron dybbin,  my suggested solutions :
-
-  * Update build
-       Are promoting usage of an update build,
-       which is prone to breakage on data model changes and is generally
-       the subject of negative prejudice.
-
-       Can eliminate this issue by making the dybinst command used by the slave
-          "./dybinst -c trunk project dybgaudi"
-       do a refresh when data model changes are detected.
-
- Enforcing external cron cut-off times introduces issues (and leads to
- complicated workarounds) :
-
-   * A build can be in-progress at cron dybbin time or the last build
-     can be broken ... meaning there is no valid build to copy.
-
-   * Uncoordinated between sites, the prevalent build at dybbin time
-     may differ between sites according to speed/breakage differences between slaves.
-
- To avoid these issues (and complicated workarounds),
- I suggest not to impose an external cron job but rather to to add a
- final step to the dybinst slave build that (if the tests succeeded)
- performs a dybbin copy "installation" into a directory named after the revision.
- And performs purging to remove excess revision directories.
-
-> One possible problem with this scheme is that our 'daily' might not match the
-> 'daily' elsewhere, but I think that could be handled, perhaps by having the master
-> define the revision number corresponding to the current 'daily'.
-
-
- Concerning coordination between slaves (although I have implemented
- such a system in the ad-hoc daily.bash) I think supporting and explaining
- complex procedures for this is not worth the effort/confusion.
-
- Simply referring to builds by their real name : '''the revision number'''
- and not the date eliminates the issue and benefits from direct
- correspondence between the state of builds reported in the web interface
- (including the timeline).
-
- Users will want to use a build after a particular
- feature has been added (or bug removed) ... thus they should
- know the minimum revision they want.
- They can then look for a corresponding build that the slave on
- their cluster succeeded to build at :
-    http://dayabay.ihep.ac.cn/tracs/dybsvn/build/dybinst
-
-Yours, Simon
-}}}
-
-
-
+= dybinst copy step =
+
+The final copy step of builds allows the update build directory to be 
+copied ( using ''dybbin pack/unpack/setup'' ) into a revision named directory.
+
+When enabled this prevents breakage of trunk from hindering progress by allowing 
+users to trivially shift a recent prior revision.
+
+== when builds/tests fail ==
+
+If a build fails (eg dybgaudi fails to compile) then the copy step is not reached 
+and no copy is made.  However if the build completes but some of the tests fail then
+the copy is still done by the name of the copied directory is changed to indicate the 
+number of failed tests.
+
+== configuration of the copy step ==
+
+The copy is configured by means of variables '''dyb_copy..''' in envfiles 
+such as  '''~/.dybinstrc'''. 
+To allow separate configuration for debug and opt builds variants of the config vars ending 
+with '''_opt''' or '''_dbg''' are accepted that take precendence over the generic vars.
+
+  * '''dyb_copybase''' : directory to which revision directories are copyied, not configuring this or the '''_dbg/_opt''' variant prevents the copying from being done
+  * '''dyb_copykeep''' : number of revision directories to be retained (defaults to 10, can have different opt/dbg settings using '''_dbg/_opt'''), others are purged
+  
+Currently the purge algorithm decides what to purge/retain based on 
+  * modification time of the revision directory
+  * number of symbolic links within '''dyb_copybase''' that point to the revision directory  
+  
+
+
+
+
+
+
+
+
+