Hello, Jenkins is still unstable. This happens from time to time. chris_c take care of fixing what is related to the test database or installing new dependencies, or things like that. I try to take care of fixing patches that cause failure, -but I must admit I don't understand easily what jenkins is usually saying- So I had 2 ideas: Idea 1 = I was wondering if we should not have a new elected position of "jenkins guardian". Idea 2 = And if we could not have the test suite in a repository different than Koha itself (or as a submodule), or if the jenkins guardian should not be able to push into $KOHA/t and $KOHA/xt The idea with a separate repository, would be that it could also have all jenkins parameters, databases, hooks, whatever,... -- 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:
Hello,
Jenkins is still unstable. This happens from time to time. chris_c take care of fixing what is related to the test database or installing new dependencies, or things like that. I try to take care of fixing patches that cause failure, -but I must admit I don't understand easily what jenkins is usually saying-
The current fails were 1/ Missing sysprefs - fixed And 3 legitimate fails Bug 5644 has a fix for one (Koha::Calendar tests) Bug 8407 and 8385 fix another (the invalid tt) The perlcritic errors are yet to be fixed afaik
So I had 2 ideas:
Idea 1 = I was wondering if we should not have a new elected position of "jenkins guardian".
Idea 2 = And if we could not have the test suite in a repository different than Koha itself (or as a submodule), or if the jenkins guardian should not be able to push into $KOHA/t and $KOHA/xt The idea with a separate repository, would be that it could also have all jenkins parameters, databases, hooks, whatever,...
I'm happy to keep looking after jenkins and more than happy to train someone else to. 95% of the errors are bad patches, only a few are db missing modules, so it's not too bad. Chris
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
Paul, Jenkins is still unstable. This happens from time to time. chris_c take
care of fixing what is related to the test database or installing new dependencies, or things like that. I try to take care of fixing patches that cause failure, -but I must admit I don't understand easily what jenkins is usually saying-
So I had 2 ideas:
Idea 1 = I was wondering if we should not have a new elected position of "jenkins guardian".
I'm not sure if this is necessary. It is up to Chris.
Idea 2 = And if we could not have the test suite in a repository different than Koha itself (or as a submodule), or if the jenkins guardian should not be able to push into $KOHA/t and $KOHA/xt The idea with a separate repository, would be that it could also have all jenkins parameters, databases, hooks, whatever,...
+1 on having tests and other QA-related code in a separate repo. Perhaps a qa-tools repo? Most of the tests should *also* be in koha.git, but in my mind it would be useful to have a separate repo so that we could A) have additional tests that might not be appropriate for inclusion into Koha (I haven't come up with any examples of this) and B) run regression tests against old versions of Koha *and* the current version, to determine whether the behavior is the same, even if the regression test is newer than the version of Koha that we know to work. Also, if we had a repo for QA tools, it might make the lives of the QA team much easier. Perhaps QAers, RMs, and RMaints should have access to a qa-tools.git repo, so that we can try to consolidate our gazillion sets of more-or-less identical QA scripts down to a single set of more-useful QA scripts? -1 on giving anyone push access to koha.git/t or koha.git/xt... it increases the chance of mishap, for very little benefit. The reason for a single RM is to make sure that someone is reviewing everything, and spotting any problems. If another individual had direct access to push their own patches (even just patches to tests), that would seem to kind of miss the point of our QA policies. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
participants (3)
-
Chris Cormack -
Jared Camins-Esakov -
Paul Poulain