[Koha-devel] About test suite & jenkins

Jared Camins-Esakov jcamins at cpbibliography.com
Fri Jul 13 23:03:49 CEST 2012


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 at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120713/5841b104/attachment.htm>


More information about the Koha-devel mailing list