Testing updatedatabase.pl changes
Hi all, In order to test such changes, I normally make an edit like: $DBversion = "3.05.00.xxx"; if (1||C4::Context->preference("Version") < TransformToNum($DBversion)) { $dbh->do("UPDATE marc_subfield_structure SET kohafield = NULL WHERE tagfield = 952 AND tagsubfield = 'f' AND kohafield = 'items.coded_location_qualifier'"); print "Upgrade to $DBversion done (remove non-existant 'items.coded_location_qualifier' column)\n"; #SetVersion($DBversion); } Note the 1 in the if and the # before SetVersion. This prevents an error on the wrong comparison (string comparison is: lt) and also an XXX in my Koha testversion. I suppose that not everybody makes such changes and therefore some updatedatabase changes are not tested well ?? (I just had one at hand while signing off.) In patch 6536 I included the following lines to eliminate such changes for testing: @@ -4396,6 +4408,10 @@ sub TransformToNum { my $version = shift; # remove the 3 last . to have a Perl number $version =~ s/(.*\..*)\.(.*)\.(.*)/$1$2$3/; + # three X's at the end indicate that you are testing patch with dbrev + # change it into 999 + # prevents error on a < comparison between strings (should be: lt) + $version =~ s/XXX$/999/; return $version; } sub SetVersion { - my $kohaversion = TransformToNum(shift); + return if $_[0]=~ /XXX$/; + #you are testing a patch with a db revision; do not change version + my $kohaversion = TransformToNum($_[0]); if (C4::Context->preference('Version')) { my $finish=$dbh->prepare("UPDATE systempreferences SET value=? WHERE variable='Version'"); $finish->execute($kohaversion); My question is: Does anybody object to submitting this change as a separate patch in order to facilitate db rev testing? I think it is an advantage to leave the version as is when you are only testing the db rev. Thanks, Marcel
Le 04/08/2011 11:36, Marcel de Rooy a écrit :
Hi all,
Hi Marcel,
My question is: Does anybody object to submitting this change as a separate patch in order to facilitate db rev testing? I think it is an advantage to leave the version as is when you are only testing the db rev.
If you look at my application as RM for 3.8, you'll see that I plan to set-up sandboxes with each ENH, to have easier testing. I was wondering how to deal with updatedatabase and the XXX. You've answered my question. So : I like this idea a lot !!! OTH : there is a small risk with this, that a forgotten XXX in a release break things a lot. How could we avoid this/limit this risk ? Just in case: I also had another idea = when setting up the sandbox, I could add in the staff news the result of any git command. Thus anyone testing the sandbox will also see what is to test on the left of the staff-homepage. Maybe we could also use this idea with this XXX stuff : if you detect a XXX during an UPDATEDATABASE, just add a news, with some red, saying "YIKES, i've detected a XXX during an updatedatabase. If you're testing a developer version, then no harm. If it's a production server, bug the developers, something has failed during version building !" -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On 8 August 2011 20:13, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 04/08/2011 11:36, Marcel de Rooy a écrit :
Hi all,
Hi Marcel,
My question is: Does anybody object to submitting this change as a separate patch in order to facilitate db rev testing? I think it is an advantage to leave the version as is when you are only testing the db rev.
If you look at my application as RM for 3.8, you'll see that I plan to set-up sandboxes with each ENH, to have easier testing. I was wondering how to deal with updatedatabase and the XXX. You've answered my question. So : I like this idea a lot !!!
OTH : there is a small risk with this, that a forgotten XXX in a release break things a lot. How could we avoid this/limit this risk ?
Just in case: I also had another idea = when setting up the sandbox, I could add in the staff news the result of any git command. Thus anyone testing the sandbox will also see what is to test on the left of the staff-homepage. Maybe we could also use this idea with this XXX stuff : if you detect a XXX during an UPDATEDATABASE, just add a news, with some red, saying "YIKES, i've detected a XXX during an updatedatabase. If you're testing a developer version, then no harm. If it's a production server, bug the developers, something has failed during version building !"
Or better use the tests and jenkins and never ever release with it set to XXX There are lots of build tests already, and every push I do to master runs them all, which means no conflict markers make it, no deprecated code makes it in etc. I'm sure you plan to continue that process, if so, theres no reason a release with XXX in it would ever get made Chris
Le 08/08/2011 10:18, Chris Cormack a écrit :
Or better use the tests and jenkins and never ever release with it set to XXX Right, I forgot this option, it's the best one, no doubt. Can you take care of it chris, or could you give me some directions to learn how to write a jenkins test (that would be usefull anyway) ?
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
* Paul Poulain (paul.poulain@biblibre.com) wrote:
Le 08/08/2011 10:18, Chris Cormack a écrit :
Or better use the tests and jenkins and never ever release with it set to XXX Right, I forgot this option, it's the best one, no doubt. Can you take care of it chris, or could you give me some directions to learn how to write a jenkins test (that would be usefull anyway) ?
Hi Paul I have sent a patch to the mailing list, if you could sign off, ill push it up so jenkins starts using it Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
I signed this patch of Chris. But still think that my idea on handling the XXX while testing a proposed (not pushed !) patch would be useful. Made a Bugzilla report for it: 6700. Please have a look at the second patch. ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Chris Cormack [chrisc@catalyst.net.nz] Verzonden: maandag 8 augustus 2011 23:41 Aan: Paul Poulain CC: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Testing updatedatabase.pl changes * Paul Poulain (paul.poulain@biblibre.com) wrote:
Le 08/08/2011 10:18, Chris Cormack a écrit :
Or better use the tests and jenkins and never ever release with it set to XXX Right, I forgot this option, it's the best one, no doubt. Can you take care of it chris, or could you give me some directions to learn how to write a jenkins test (that would be usefull anyway) ?
Hi Paul I have sent a patch to the mailing list, if you could sign off, ill push it up so jenkins starts using it Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
Le 10/08/2011 17:02, Marcel de Rooy a écrit :
I signed this patch of Chris. But still think that my idea on handling the XXX while testing a proposed (not pushed !) patch would be useful. I signed it as well, didn't the mailing list recieve my sign-off ?
Made a Bugzilla report for it: 6700. Please have a look at the second patch. will do, thanks for reporting.
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (4)
-
Chris Cormack -
Chris Cormack -
Marcel de Rooy -
Paul Poulain