Enable GitHub CI (testing) workflows

[jmckenna]

• for all readers: "CI" = continuous integration testing, so, when someone makes a request to add to the ZOO-Project source code, triggers are automatically enabled to test the new proposed code on various build systems (Ubuntu, Clang, MinGW, etc).
• previously all Open Source projects used TravisCI
• recently a lot of projects (long story) have moved to GitHub "workflows" or "actions" for CI testing
• see the long list of configured tests now by GDAL at https://github.com/OSGeo/gdal/tree/master/.github/workflows

This CI testing is critical for a project. This is a must, as part of our "GitHub migration" plans.

[gfenoy]

In ZOO-Projecct we used appVeyor for years to check if build procedure work there https://ci.appveyor.com/project/djay/trunk-t67ri and https://ci.appveyor.com/project/djay/trunk-hp3tw.

On the other hand, the Docker image that can be build using the docker-compose.yml may also be another way to both test, build and publish the docker binary image.

It is probably a good starting point for building and testing.

I would personally be in favor of the second option.

[omshinde]

I second using Github Actions and Docker. Found this which might be helpful for our reference: https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action.

[gfenoy]

I think that this issue ZOO-Project/ZOO-Project#2 is related to this one.

[gfenoy]

I am wondering if the documentation should not also be generated using GitHub action.

If we go this way then, we can also imagine the same kind of generation / publication for workshop materials for instance.

[omshinde]

It would be great to automatically generate documentation using Github Action. I am curious to learn about this. :-)

[gfenoy]

During the last OGC Code Sprint, @samsouk and I had published a first GitHub Action for producing and publishing the docker image. Please see here for more details.

Yesterday, I started integrating tests by using the cptesting we made available some years ago, within the same GitHub Action.

The issue by now is that, the test script is producing HTML output but it would then require publication of the resulting HTML pages to ease the read. So, to me there are two options:

1. Store the produced HTML pages, then aggregate them to produce a readable output online to be checked to ensure that the tests passed all or some failed,
2. Change the test script for outputting only simple text showing the same kind of information that is already provided.

[gfenoy]

I have integrated the support of local cache when building the Docker image. Also, now the testing for GetCapabilities and DescribeProcess are run for both 1.0.0 and. 2.0.0 versions.

Still, the test script would benefit of being rewritten in a way that it would fail in case any unexpected behavior is found rather than having to be checked by us to verify the produced test outputs.

Any idea?

[omshinde]

I have integrated the support of local cache when building the Docker image. Also, now the testing for GetCapabilities and DescribeProcess are run for both 1.0.0 and. 2.0.0 versions.

Still, the test script would benefit of being rewritten in a way that it would fail in case any unexpected behavior is found rather than having to be checked by us to verify the produced test outputs.

Any idea?

@gfenoy It would be nice to have test scripts instead of checking it everytime it is compiled. I was thinking what could be "unexpected behavior". Can we check for status code or the received response for GetCapabilities request?

[gfenoy]

@omshinde actually there are multiple tests running already starting from line 54. Not only triggering GetCapabilities but, checking the response is conform to the schemas is also handled there. Same occur for DescribeProcess, for this two first requests we get support for version 1.0.0 and 2.0.0.

For the ExecuteSync and ExecuteAsync test cases only version 1.0.0 is supported until now. Some work should be handled to support 2.0.0, specifically the creation of sample XML Execute content to be posted to the server for testing.

To answer your question about "unexpected behavior" can be that the Execute request that should return status code 200 does return something else. Another example would be, in case you provide a wrong value for a parameter then you should receive an exception report with a given status code.

Finally, for completeness it would be worth it considering "Annex A: Abstract test suite" and double check that the cptesting testing tool is following every single test from the "Server test module" (A3). Maybe, to add clarity, we can also plan to provide a reference for every tests from the A3 section and display their names right before the test results.