On Friday 14 September 2007 00:46, Michael Short wrote: > While doing some further tests on windows I began to realize that there is > no reason why the regression scripts should use the source for any kind of > testing. The code is compiled on a completely different platform and > copying the entire source tree to a different machine/vmware seems like > more work than it should be. Perhaps the win32 regression scripts could be > configured to use the nsis installer to setup the regressions instead of > actually copying the binary files from bacula/src/win32/installer/release. > This way doing regression testing would be as easy as copying > winbacula-*.exe to a directory and running a batch script.
Why is copying the entire source tree then running a batch script any harder than coping winbacula-*.exe, installing it, and running a batch script? There are a number of reasons why we use the full source: 1. Normally getting the regression scripts and the source that are up to date are a matter of doing one time at the very beginning: svn checkout <bacula-source> bacula svn checkout <regress-source> regress then before every regression: cd bacula svn update cd ../regress svn update very simple, and can be done by a script. This ensures that you are running on the current source. 2. The source code once built provides a nice reasonable test set of files for backing up and restoring (i.e. it backs up and restores itself). It is a known size and a known number of files, and in a known location, so there is no twiddling with scripts to point to the correct FileSet, and there is no searching to find FileSets that are a reasonable size -- not too small and not too big. 3. The regression scripts do not use a production environment, and if used carefully can be run on a production machine -- I run my biggest regression tests on my production backup machine. To do this requires a special non-production installation. The same svn procedure could be used on Win32 to update the source and update the regress scripts, but there is one problem and that is that the released version of Win32 is cross-compiled on Linux, so for doing Win32 testing, one still must pass via a Linux machine to get everything 100% current. If you have to copy winbacula-*.exe to the Win32 machine, I don't see what is hard about copying the whole directory tree. With a Samba mount to a Linux machine, you can script the Win32 machine to automatically pull down a pre-build directory. > > The only issue with using the installer is that the installer cannot > install everything without user intervention. I believe that it can since it has command line arguments, but that does not resolve the above problems. > Perhaps the installer could > be configured to accept user-arguments which specify the different install > modes and options. This would solve a number of problems for Win32 > regressions and also include testing the installer as part of the > regression tests. > > Let me know if I am not being reasonable with this :P I don't see that your proposal really solves much other than doing some testing of the installer. Regardless of whether you pull a full directory (the whole source tree) or only winbacula-*.exe, you must pass by a build on a Linux machine. In face, it seems to me your proposal will significantly complicate things -- read on for the reasons... The disadvantage of what you are suggesting is that you cannot do regression testing on a production machine or one that has a FD installation. In addition, you would have to make some modifications to the current scripts so that the multitude of .conf files that the regression scripts use could be installed in the right places on the Win32 machine, which is far from simple since the directory paths of where the conf files are installed are dependent on the OS version and the language it is configured for. The current regression tests pull everything from a single file. Regards, Kern > > Sincerely, > -Michael ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
