Add make test-kitodo

[markusweigelt]

No description provided.

[markusweigelt]

Atm we call make test and run all test. Possibly only test-kitodo and test-presentation is still necessary as the test-production is indirectly tested by test-kitodo.

[bertsky]

Excellent!

[bertsky]

Very nice recipe!

[bertsky]

Possibly only test-kitodo and test-presentation is still necessary as the test-production is indirectly tested by test-kitodo.

Yes, but test-production (alone) tests in sync mode, which is good for coverage.

BTW, on the CI we could do make -j test which will run all 3 tests in parallel. To make that work with the Controller, we can either add CONTROLLER_WORKERS=3 make -j test so that they will actually be computed in parallel, or keep the default 1 (which will have each job wait for the previous job to free the semaphore). We could even test both...

[markusweigelt]

BTW, on the CI we could do make -j test which will run all 3 tests in parallel. To make that work with the Controller, we can either add CONTROLLER_WORKERS=3 make -j test so that they will actually be computed in parallel, or keep the default 1 (which will have each job wait for the previous job to free the semaphore). We could even test both...

Probably we have to adjust the make call in Makefile too

ocrd_kitodo/Makefile

Line 153 in 6f665a2

$(MAKE) -C _modules/ocrd_manager $@

.

Atm rerunning of test-kitodo without make down and make start is a problem cause we need to flush the manager log to provide the check for KitodoActiveMQClient if ocr processing has finished.

ocrd_kitodo/Makefile

Line 169 in c3d29a5

( timeout 5m docker logs -f `docker container ls -qf name=ocrd-manager` & ) | grep -q "KitodoActiveMQClient"

truncate -s 0 $(docker inspect --format='{{.LogPath}}' ocrd_kitodo-ocrd-manager-1 ) flush's the log with sudo but probably there are permission issues without sudo at the runner. But i will check this.

[bertsky]

Atm rerunning of test-kitodo without make down and make start is a problem cause we need to flush the manager log to provide the check for KitodoActiveMQClient if ocr processing has finished.

indeed.

But truncating the Docker log file is asking for trouble. I'd rather keep it simple and require down-up.

Or is there another way to query the ActiveMQ was received, perhaps something on the process directory?

[markusweigelt]

Yes. Instead of testing for existing KitodoActiveMQClient request in log, we can check if the alto files are already in the directory. If they are not present within of 5 minutes, an error will be thrown. We would only have to delete the alto directory before rerun next test.

[bertsky]

Yes, sounds good. (Or directly intercept the ActiveMQ result by interacting with our kitodo-mq container?)

[markusweigelt]

Changed the implementation to check for existing of an alto file.

[bertsky]

But I really like the ActiveMQ test better!

(Even if that means you cannot easily repeat. And why not try to test directly for the ActiveMQ reply? For example, we could do docker exec kitodo-mq bin/activemq consumer --messageCount 1 ...)

[markusweigelt]

Add the issue #64 and merge branch as discussed