add redirect test workflow / github action

[simontaurus]

Currently there are no or only limited pre-deployment testing options (see also #1629).

This pullrequest adds a workflow that can be run in the main repo, any fork or on local checkouts if docker is available.

Test specifications are currently extracted from .htaccess file comments, e. g.

##TESTv1 '/mypath --header "Accept: text/html"' "https://my-target-domain.com/test.html"

Example: 4892875

Contributors can run the github action in their forks selecting only the subpath of interest:

Example: https://github.com/OpenSemanticWorld/w3id.org/actions/workflows/redirect_tests.yml

Run will fail if at least one test is not successful, log will show errors e.g.

Processing file /usr/local/apache2/htdocs/emmo/.htaccess
TEST '/emmo/domain-test --header "Accept: text/html"' => 'https://emmo-repo.github.io/domain-test/test.html'
ERROR  : Result is 'https://raw.githubusercontent.com/emmo-repo/EMMO/domain-test.ttl'
TEST '/emmo/domain-test --header "Accept: application/rdf\+xml"' => 'https://emmo-repo.github.io/domain-test/test.ttl'
ERROR  : Result is 'https://raw.githubusercontent.com/emmo-repo/EMMO/domain-test.ttl'
Error: Process completed with exit code 1.

Example: https://github.com/OpenSemanticWorld/w3id.org/actions/runs/7224639650/job/19686349546

More details can be found here: https://github.com/OpenSemanticWorld/w3id.org/blob/master/.test/README.md

Let me know if that makes sense to you and if I should stash my commits

[davidlehn]

This is an interesting testing approach. Thanks. We'll probably need to think this over a bit.

• Probably could slim down that apache config since it's mostly comments. I can check our production config to line things up so it's doing realistic testing.
• I didn't know workflows could have inputs like that.
• Based on the old travis-ci linkchecker experiment, we don't want to default to running all the tests in every dir. As this service grows, so do bitrotten configs and links. Need to avoid other peoples broken setups causing false positive failures for a PR.
• For a long while, I've had ideas for other checks that should also be run. For that I wanted to do something to look at the PR changed files and only run tests in those dirs (or whatever makes sense). So if you you edit files in /foo and /bar in a commit, it would only check those dirs. Seems like something similar could be applied here. I'm not sure the implementation details of that.
• Ideally we'd run this sort of thing by default. To avoid wasting cycles, probably would want a pre-action that quickly checks what tests should even run. No reason to spin up docker and apache if no tests exist.
• For my other project ideas, I was considering a .w3id.json (or .yaml, .etcetc) config. Do you think it would be better to have test pragmas inline in .htaccess? Or would a more easily parsable file with test info be ok? I can see pros/cons there.

[simontaurus]

Diffs to the default config: Rewrite modul must be enabled

[simontaurus]

Diffs to the default config: AllowOverride must be enabled in the target directory

[simontaurus]

This is an interesting testing approach. Thanks. We'll probably need to think this over a bit.
...

• I agree it would be best to use the actual config. The current file is the default apache config with two changes applied (see comments)
• have to admit I also just found out =)
• I was keeping that in mind with the search path option
• the workflow now checks only changed dirs on pull requests, example: Redirect tests opensemanticworld/w3id.org#9
• good point. I've added a precheck before the docker steps, example: https://github.com/OpenSemanticWorld/w3id.org/actions/runs/7229780356/job/19701078363
• Maybe we can support both (need to agree on the formats of course). My idea was that it's most convenient to write the tests directly above the rules that should cover the cases. This also provides additional documentation since the tests show what we actually want to achieve.