We can setup this in a way that unit tests are running on every commit to master (the usual at Sourceforge). This kind of tests, should be run at developer system, before pushing to repository.
Then the "acceptance" tests (the ones from Allin), and the gretl examples tests, functions, packages, only at a special branch (we manage this at GitHub).
The same for the GUI tests (after we create them).

Another possibility is to have a "release" branch, that produces the installer for all systems and then runs the whole bunch of tests.

Other thing that may be useful, is to setup SonarCloud for code quality and security checks. This setup must be done by the owner of the GitHub project, and it is failing because is using my project ID.

We can plan the tests separation to exist in a different branch, or even a different repo/project.

On Thu, May 9, 2024 at 11:17 AM Artur T. <atecon@posteo.de> wrote:

Am 09.05.24 um 12:08 schrieb Sven Schreiber:
> Am 09.05.2024 um 11:34 schrieb Artur T.:
>> Am 09.05.24 um 02:20 schrieb Cottrell, Allin:
>>> 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.
> Weren't those test scripts integrated into the git source tree in the
> meantime? Specifically, what does /unittests contain? (Not to be
> confused with /tests !)

In the gretl source, to be more concrete under ./gretl/unittest one can
find a collection of -- as the name says -- unit-test for gretl-built
functions and commands.

In the workspace under ./gretl-workspace/testgfn you can find a
mechanism to download and run sample scripts.

And then there exists ./gretl/tests. But I don't know anything about this.

Artur

>>> 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.
> Not sure whether the workspace is open for everybody. Hélio, if you run
> into problems while accessing it, please tell us.
>>
>>
>> it would be useful, if we could also automatically run those sample
>> scripts via github-actions each time a new commit gets pushed.
>>
>> @Helio: Do you think, you have time to set this up on github? I could
>> assist you if you need any help.
>
> Yes, it would be great if this could be automated, so this would be very
> welcome. However, I would suggest not to trigger it on every commit, for
> reasons of sustainability and energy savings. Maybe once per day would
> be enough.

Not sure if this can be set up this way. Needs to be checked. Usually,
you develop on a dev-branch, and you run the whole test-suit when or
before pushing to master.

Artur
_______________________________________________
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-leave@gretlml.univpm.it
Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/