On Friday 14 September 2007 23:37, Michael Short wrote: > I realize that it could be a bit of work to change the installer to > automatically setup a regression install, but it would also make > maintaining the regression scripts much easier. Using the installer would > also ensure fewer differences between a production environment and a test > environment. The win32 regression scripts handle bacula regression very > manually, so any major change would cause the scripts to fail. However, if > we use the installer we won't have two make two sets of changes for every > major update. It should also be noted that NSIS makes it very easy to > create a customized service (as I have used this for some time with bacula) > for the purpose of separating a production service from a testing service. > > I don't mean to seem repetitive about my original statement, but the bacula > source tree alone weighs about 322mb when combined with ming32 binaries > (not including regress and docs). Since windows does not really handle lots > of small files well it could potentially take hours to transfer the files > individually over a share, or compressed. Tarballs help with this problem, > but it is still a file that must be manually created and transferred. > Theres nothing wrong with bacula using its own install as a file testbed. > > Though I understand that there may not be reason enough to make these > changes due to lack of time or focus. This is not really an immediate > issue, but since I can't contribute much else I might as well take a look.
I don't have a problem if you want to take a look. However, it might be easier to write a new .nsi file rather than try to modify the existing one. The only downside is that it would require maintaining two files. > > Sincerely, > -Michael > > On 9/14/07, Kern Sibbald <[EMAIL PROTECTED]> wrote: > > On Friday 14 September 2007 12:50, Michael Short wrote: > > > Seems fair, though it is worth mentioning that the installer could be > > > > made > > > > > automatic for regression purposes (to prevent clobbering any kind of > > > production installation). > > > > That is certainly possible but would be a significant amount of work. > > > > > At the moment the regression scripts reinstall > > > bacula as a service anyways. > > > > I didn't know that. I'm a bit surprised since it is not necessary to run > > it > > as a service to do the testing. > > > > Regards, > > > > Kern > > > > > Sincerely, > > > -Michael > > > > > > On 9/14/07, Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > > 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 ------------------------------------------------------------------------- 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
