Properly handle test zim files with git-lfs

[mgautierfr]

For now we have a bunch of test/reference zim file directly in the libzim repository. All those files represent around 33Mb and ~1,4Mb is updated time to time.

We don't want that :

• We don't want to have test data to change. They are somehow a reference and libzim must handle "correctly" previous version of test data.
• We pollute our git history. Git is not good to manage binary data.
• We will add more test data with time.

I'm open to idea here, but I propose :

• Create another repository containing some reference data and script generating the test/reference zims.
• CI will run on this repository and will generate a archive containing all test data and some metadata (which zims are valid or not. What kind of error to expect. Some reference data associated to zims files to check reading,. ...)
• Other projects (libzim, but also zim-tools, kiwix-*, ...) will download this archive (potentially configurable to point to a specific data directory) and will test using the zim files in the archive.

Tests would be designed to be extensible (add/change zim files) without having to change the tests itself (auto-discover test files, from filename or metadata information)

[kelson42]

@mgautierfr git-lfs seems to be a good solution, but the free storage on Github is limited to 1GB and the bandwidth to 1GB /month. Any channce we could stay within the free plan limit?

[mgautierfr]

We can store the generated data using git-lfs instead using a archive yes.

The data is not intended to change. If we want to test a new point, we will add data, not change it. Except if we put big zim file we should stay under 1GB for a (long) time. About the bandwidth, depends of several things:

• The dev/user. Ideally, they should set the data repository only once and make dev repository point to the data repository. But they may do differently and download several times the data.
• The CI. The data repository will be setup by all jobs in our CI. If the CI is not taken into account in the bandwidth limit we are good. But else we will hit the limit pretty quickly.

[kelson42]

@mgautierfr OK, I think we should carry on.

[Deburama1]

Hello, I am new to open source contribution, how can I contribute to this code as a first issue.

[kelson42]

@Deburama1 Hi and welcome, unfortunately there is nothing much we can do if you don't know how to fix the issue.

[kelson42]

@mgautierfr What should we do with this ticket? Close it? Move it to zim/zim-test-suite?

[mgautierfr]

We can move it to zim-test-suite yes.