Test for ocrd-network

[joschrew]

This PR adds a test for ocrd-network. Purpose is that the test is available in the docker-image and can then be used with ocrd_all. It does not run with just core itself ( I am not sure if it is good to do it this way, because it is not supposed to run with "just" plain core).

This PR is required for: OCR-D/ocrd_all#407

[bertsky]

I don't see a problem integrating this into core proper.

Even the workflow file should be here (besides dummy-workflow.txt), not in ocrd_all.

And core/tests/network/docker-compose.yml could already bind-mount it to the right location. (This compose file in turn can be included in ocrd_all's compose file.)

Since that workflow test cannot be run without ocrd_all, it should simply be skipped by default.

[kba]

I don't see a problem integrating this into core proper.

Even the workflow file should be here (besides dummy-workflow.txt), not in ocrd_all.

And core/tests/network/docker-compose.yml could already bind-mount it to the right location. (This compose file in turn can be included in ocrd_all's compose file.)

Since that workflow test cannot be run without ocrd_all, it should simply be skipped by default.

I see the benefit of DRY and composing the behavior from existing/proven docker-compose.yml. However, I think in this case I think it would be better to not depend on OCR-D/core for the intergration test:

• it requires some hard-to-read constructs, like build: !reset null and inconsistent relative paths in the derived docker-compose.yml
• Changing the workflow to run requires updating core
• The reusable parts, i.e. up RabbitMQ, MongoDB and processing server is generic enough that the benefit of a simple setup (one directory in ocrd_all with the workflow(s), docker-compose.yml and pytest scripts) outweighs the drawback of having some redundancy.

[bertsky]

• Changing the workflow to run requires updating core

ok, good point!

• The reusable parts, i.e. up RabbitMQ, MongoDB and processing server is generic enough that the benefit of a simple setup (one directory in ocrd_all with the workflow(s), docker-compose.yml and pytest scripts) outweighs the drawback of having some redundancy.

there's a lot of stuff in there, which will still likely evolve a lot. This would have to be synced with ocrd_all then.

If we don't want to inherit/include from core, perhaps we could just have a makefile rule cp from core, and have a few git-controlled override files in place (like docker-compose.override.yml)?

[kba]

I would expect SKIP_ASSETS=0 to disable the behavior. Did you mean test $SKIP_ASSETS -eq 1?

[MehmedGIT]

I think SKIP_ASSETS should be renamed to MAKE_ASSETS to reverse the logic.

SKIP_ASSETS itself has a negative meaning. False to False makes True.

SKIP_ASSETS=1 (true) -> do not make assets
SKIP_ASSETS=0 (false) -> make assets

[joschrew]

for me 0 is false so if SKIP_ASSETS is 0 then it is not skipped.