-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dockerfile update #96
Conversation
Dockerfile
Outdated
@@ -1,6 +1,6 @@ | |||
# Patch and build Olena from Git, then | |||
# Install OCR-D wrapper for binarization | |||
FROM ocrd/core | |||
FROM ocrd/core:v2.62.0 AS base |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If similar changes are made for more processors, new releases of OCR-D would require a lot of additional work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle – yes. But practically, the opposite is true – without pinning to a specific version, the module maintainers are always forced to react timely to things broken by upstream OCR-D. By pinning, we the maintainer can make a conscious decision on whether and when to update.
Of course, we should at some point do the same thing with pure Python requirements. But for native installation (or ocrd_all via Docker) we currently cannot, because as long as our packages will live in a large unisolated venv, pinning would immediately shrink the intersection of compatible versions to zero. On the other hand, Docker modules are the way to go for greater isolation, and pinning here will now on offer some protection against breaking changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think the added effort of hardcoding a specific version is worth the reproducibility and since it does not concern the deployment with ocrd_all (yet), I see no reason not to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you also might want to make the same modification (labels) to the build-olena.dockerfile (which is Olena-only, without OCR-D wrapper).
Also, perhaps it's time to make this a single proper multi-stage Dockerfile...
Just to confirm, do you think this is ready to be merged? I realized I probably could merge it myself which I would try to do if so. I agree that a multi stage build would be nice. I looked into it but I think I cannot do it and I think this could be regarded as another separate issue. And to me it is not clear what the advantage of the olena-only image is except from size. |
Yes, I think it's ready for merge and will do so later, thank you! |
Co-authored-by: Stefan Weil <[email protected]>
@kba do you have any idea what might be the problem with the Dockerhub deployment? On CircleCI build-docker, I see
But the credentials have not been touched in 9 months, nor has the CI config changed in 2 years... |
This PR is part of series to offer single ocrd modules as Docker Containers (ocrd slim containers) to be used with ocr-d network.