[Feat] Cache NC sample data for tests in CI

[wenzeslaus]

Is your feature request related to a problem?

Tests running on Ubuntu download the test data every time they run.

The URL is:

https://grass.osgeo.org/sampledata/north_carolina/nc_spm_full_v2alpha2.tar.gz

Describe the solution you'd like

GitHub Actions cache is used instead of a download inside the test script.

Describe alternatives you've considered

All these would be good improvements in addition to cashing but reducing the need for cashing at the same time:

• Smaller dataset for test (identify what tests needs and what tests can do without)
• New stable dataset combining old full and basic NC SPM with tests fixed accordingly (now the two datasets are basically merged with duplication)
• Better compression.

Additional context

The caching in GitHub Actions was broken in the past, but now it consistently works.

[adinayyu]

I am adithya from India and as part of gsoc 2022 i want to work on support writing tests with pytest project. I want to work on this issue to contribute to osgeo. How to work on this issue and this is my first issue

[wenzeslaus]

That's great, but not ideal. This issue is related, but not that relevant to the pytest GSoC idea. It is not a good test of skills because this is YAML configuration for GitHub Actions, but for the pytest GSoC idea you need Python in context of GRASS GIS. In other words, you could do all what is needed for the GSoC project without ever touching these YAML files. So, while this might be a great start for contributing, you will need to write some Python code for the GSoC application, too.

What I recommend in the grass-dev post from Apr 6 still applies, i.e., fix one of the existing tests listed in .gunittest.cfg and write a new test similar to utils_test.py or reprojection_renderer_test.py.

With that said, the best way to work on this issue is to find GitHub documentation for cashing in GitHub Actions and existing examples (something like this).

It is up to you if you want to pursue this to get familiar with the contributing workflow. Likely, this whole issue can be addressed just using the online web interface of GitHub without ever installing GRASS GIS locally, so this makes it a great first issue. The GSoC test of skills for the pytest idea, needs Python code.

[adinayyu]

That's great, but not ideal. This issue is related, but not that relevant to the pytest GSoC idea. It is not a good test of skills because this is YAML configuration for GitHub Actions, but for the pytest GSoC idea you need Python in context of GRASS GIS. In other words, you could do all what is needed for the GSoC project without ever touching these YAML files. So, while this might be a great start for contributing, you will need to write some Python code for the GSoC application, too.

What I recommend in the grass-dev post from Apr 6 still applies, i.e., fix one of the existing tests listed in .gunittest.cfg and write a new test similar to utils_test.py or reprojection_renderer_test.py.

With that said, the best way to work on this issue is to find GitHub documentation for cashing in GitHub Actions and existing examples (something like this).

It is up to you if you want to pursue this to get familiar with the contributing workflow. Likely, this whole issue can be addressed just using the online web interface of GitHub without ever installing GRASS GIS locally, so this makes it a great first issue. The GSoC test of skills for the pytest idea, needs Python code.

Sir thanks for clarification Where to ask queries related to fixing existing tests in .gunittest.cfg

[wenzeslaus]

The grass-dev mailing list is the best place to ask how-to questions about development.