slub / ocrd_controller

Path to network implementation of OCR-D
MIT License
6 stars 3 forks source link

Update publish.yml to build stable version #25

Closed markusweigelt closed 1 year ago

markusweigelt commented 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.

bertsky commented 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.

bertsky commented 1 year ago

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.

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.

markusweigelt commented 1 year ago

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 😎

bertsky commented 1 year ago

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).

markusweigelt commented 1 year ago

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.