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.
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
