Closed markusweigelt closed 1 year ago
After we have created the stable branch we still need to adjust the docker-compose.yml and add the version argument for the parent version.
You mean the OCRD_ALL_VERSION
?
Actually, I now believe we should track that in the repo itself. So the build-args would read from a repo-managed file – say base.version
– which naturally on master would simply be maximum-git
but on stable represent a date release which we could edit every once in a while.
Actually, I now believe we should track that in the repo itself. So the build-args would read from a repo-managed file – say
base.version
– which naturally on master would simply bemaximum-git
but on stable represent a date release which we could edit every once in a while.
Or better yet: track ocrd_all as a subrepo (without checkout or even recursive checkout of course). The same could be done for core in ocrd_manager.
This all sounds like a lot of overhead than adding single build arg to docker-compose only in the stable branch.
Btw cool there are ocrd/core version distinctions on Docker Hub now 😎
This all sounds like a lot of overhead than adding single build arg to docker-compose only in the stable branch.
indeed, forgot about that. Let's use only that then!
Currently, we pass VCS_REF and BUILD_DATE dynamically, and your new OCRD_ALL_VERSION
gets set on the CI statically. IMO the latter would need to be changed. Instead, set VERSION
in docker-compose.yml directly, so it can be version controlled (and also applies for local builds via Dockerfile btw).
Solved it a bit differently but almost as good (since the current docker/build-push-action
works so well incl. caching etc.). I hope it fits like this.
After we have created the stable branch we still need to adjust the docker-compose.yml and add the version argument for the parent version.