Thanks, Helio. What you reference via the link below is my "personal"
collection of test scripts (which has evolved since then). Of course
anyone is welcome to run these tests, but I haven't made a serious
effort to make them portable for others.
But what Sven and I were talking about is a bit different: it's an
apparatus for downloading all the current publicly-available gretl
function packages (.gfn or .zip files) from sourceforge, and checking
that the "sample script" inside each of the packages runs
successfully. Any failures on this test will (or should!)
automatically hold up a planned gretl release until they're fixed.
This apparatus can be found at
https://sourceforge.net/p/gretl/workspace/ci/master/tree/testgfn/ i'll
be happy to try answering any questions you may have.
Allin
On Wed, May 8, 2024 at 6:30 PM Hélio Guilherme <helioxentric(a)gmail.com> wrote:
>
> These are the "acceptance" test I got from Allin, some years ago:
https://github.com/HelioGuilherme66/gretl/tree/gretl-tests/gretl-tests/te...
>
> On Wed, May 8, 2024 at 11:25 PM Sven Schreiber <sven.schreiber(a)fu-berlin.de>
wrote:
>>
>> Am 08.05.2024 um 23:08 schrieb Cottrell, Allin:
>>
>> On Wed, May 8, 2024 at 3:58 PM Sven Schreiber
>> <sven.schreiber(a)fu-berlin.de> wrote:
>>
>> Agreed, this needs to be fixed in the package. However, from the
>> timeline of the release of gretl 2024a on April 5th, it would mean that
>> the package should have failed already in the run-up to the release. My
>> question then is, why didn't we notice? I thought it's a standard part
>> of the testing parcours to check the sample scripts of all packages.
>>
>> You're right. I'm afraid there was a testing failure in this case. All
>> the gfns had been tested probably a day before the March 29 change,
>> and at the time it didn't seem that anything "significant" had
changed
>> between then and the April 5 release. But that's a risky assumption,
>> and not one I'll make in future. Obviously, it would be good if I were
>> not the only person testing all the gfns' sample scripts in the run-up
>> to a release.
>>
>> Yes, we should better distribute those tasks.
>>
>> thanks
>>
>> sven