Try to fix ctest id problem identified by Frank

git-svn-id: https://bacula.svn.sourceforge.net/svnroot/bacula/trunk@6545 91ce42f0-d328-0410-95d8-f526ca767f89

diff --git a/regress/README.ctest b/regress/README.ctest
index 6f1c902733c6edc8a749a79eede5d22bb4a3131a..9b8986ad8ef0ce8e5b3dddb703862fc1a0b2c4e3 100644 (file)
--- a/regress/README.ctest
+++ b/regress/README.ctest
@@ -84,3 +84,84 @@ Results will not be visible as soon as they are submitted to the server.
 Processing is currently done every 10 minutes, so you may have to wait up to 15
 minutes or so before your results show up.
 
+=========================================================
+
+Email from Frank describing the flow when running a ctest and some of the
+problems that come up.
+
+0. Start off with a local svn repository at version A, and the master 
+repository at version B.
+
+1. nightly-disk is started.
+
+2. nightly-disk runs scripts/config_dart
+
+3. config_dart runs scripts/create_sed
+
+4. create_sed pulls bversion and bdate out of the current local repo, so gets 
+version A values.
+
+5. config_dart then creates DartConfiguration.tcl from the .in file, leaving a 
+BuildName parameter of A.
+
+6. nightly-disk then runs 'ctest -D Nightly'.  This implicitly tells ctest to 
+perform Update, Configure, Build, Test, and Submit stages, in that order.
+
+7. The Update stage runs 'svn update' on the local repository.  The local 
+repository is now updated to version B from the master, but since the 
+DartConfiguration.tcl file was already created and has not been updated, the 
+Update.xml file has the version A BuildName still.
+
+8. Next, the Configure stage runs.  Since the configure process is handled in 
+tandem with the build process by 'make setup', this just calls /bin/true so as 
+to not throw any false errors, and can effectively be treated as a no-op.
+
+9. Next is the Build stage, which is handled by calling scripts/update-ctest.
+
+10.  update-ctest checks the svn versions of regress/build vs BACULA_SOURCE. 
+Since the two are different (regress/build is still version A, while 
+BACULA_SOURCE has been updated to B) it calls 'make setup'.
+
+11. 'make setup' copies BACULA_SOURCE to regress/build and configures and 
+builds it.  It then calls scripts/do_sed
+
+12. do_sed calls scripts/config_dart again.  Since regress/build has been 
+updated to B, it regenerates DartConfiguration.tcl with a version B BuildName.
+
+13. ctest now generates the Build.xml results file, but since BuildName was 
+still A while this stage began, this is what appears in the XML BuildName.
+
+14. Done with the Build stage, ctest moves on to the Test stage, where it 
+actually calls the various test/ scripts as defined by DartTestfile.txt and 
+filtered by the -R option.  At this point, since ctest is beginning a new 
+stage, it appears to re-read DartConfiguration.tcl (I believe this is intended 
+to allow ctest to bootstrap itself in a virgin cmake managed source code tree, 
+where the test configuration should be generated by cmake).  The final 
+Test.xml file, therefore, contains a version B BuildName string, as opposed to 
+all previous steps, which have version A.
+
+15. Finally, ctest flings the results at the dashboard.  The dashboard does 
+ignores in what order or grouping XML files are submitted, and instead uses 
+the site/buildname tuple to distinguish them (at least for Nightly runs, I'm 
+not so sure about Experimental ones).  In this case, instead of one complete 
+run, the dashboard sees two runs, one of which is Update through Make, and a 
+second one which is Test only.
+
+For a sample of the problem, take a look at the fsweetser 2.3 sqlite3 Nightly 
+runs at
+
+http://regress.bacula.org:8081/Bacula/Dashboard/Dashboard?trackid=29
+
+The Update and Build information show up with a BuildName of 
+bacula-2.­3.­10-26Feb08-Linux-sqlite3, then after svn update hit the Test 
+information shows up with bacula-2.­3.­11-03Mar08-Linux-sqlite3.  (Ignore for 
+the moment the fact my timestamps are at 6:59PM, rather than at 9PM where 
+they're supposed to be; this seems to be a Fedora specific client side issue I 
+haven't tracked down yet.)
+
+Looking more closely at the test submitted to the public dashboard 
+(http://public.kitware.com/dashboard.php), I get the impression that the 
+BuildName parameter was misnamed, and intended to be treated more as a build 
+platform name, rather than the name of the build being tested.  Rather than 
+create a hook to tag the version being tested, everyone as far as I can tell 
+just seems to rely on the timestamp of the test.

diff --git a/regress/scripts/config_dart b/regress/scripts/config_dart
index 324915a5dce186e7dc4e3e999d14d1e971869817..264acb7731289040a116a70ea375e430f5eb6abb 100755 (executable)
--- a/regress/scripts/config_dart
+++ b/regress/scripts/config_dart
@@ -4,9 +4,15 @@
 #
 cwd=`pwd`
 . ${cwd}/config
+
 mkdir -p ${cwd}/bin
 out="${cwd}/tmp/sed_tmp"
 
+# pull in latest Bacula version
+cd ${BACULA_SOURCE}
+svn update src/version.h
+cd ${cwd}
+
 scripts/create_sed