Adjust image names to GitHub Container Registry image names

[bertsky]

I suppose this must wait until all the subrepos adopted the respective GH Actions?

Also, are you sure about using markusweigelt in the tags everywhere? That would require updating your fork of ocrd_controller automatically, I guess. Isn't that a problem if we don't link to the fork? As for ocrd_monitor, I suppose it was never a good idea to use bertsky here (deviating from the repo).

[markusweigelt]

I suppose this must wait until all the subrepos adopted the respective GH Actions?

The mainrepo has it's own workflow to build image from respective module. Therefore it is not necessary to wait.

Also, are you sure about using markusweigelt in the tags everywhere?

The image must be named according to the following scheme ghcr.io/OWNER/IMAGE_NAME. As I understand it, the OWNER can only be an organization or a user. For organization repositories we need to have access to one suitable for example https://github.com/slub.

That would require updating your fork of ocrd_controller automatically, I guess. Isn't that a problem if we don't link to the fork?As for ocrd_monitor, I suppose it was never a good idea to use bertsky here (deviating from the repo).

For our perspective GitLab repository/fork, the workflows are not executed. For the forks, I don't think you can just overwrite the images. We might have to introduce a variable for the OWNER to provide repo packages on your own fork otherwise the workflow will probably just fail. Is that what you meant by the question?

[bertsky]

I suppose this must wait until all the subrepos adopted the respective GH Actions?

The main repo has it's own workflow to build image from respective module. Therefore it is not necessary to wait.

But what if I don't want to make build, but have make start pulling the prebuilt images?

Also, are you sure about using markusweigelt in the tags everywhere?

The image must be named according to the following scheme ghcr.io/OWNER/IMAGE_NAME. As I understand it, the OWNER can only be an organization or a user. For organization repositories we need to have access to one suitable for example https://github.com/slub.

Yes, that's why I raised the point. (And I'm fine with switching to slub everywhere, but we would first have to transfer the repos, which I don't think we can do ourselves.)

That would require updating your fork of ocrd_controller automatically, I guess. Isn't that a problem if we don't link to the fork?As for ocrd_monitor, I suppose it was never a good idea to use bertsky here (deviating from the repo).

For our perspective GitLab repository/fork, the workflows are not executed. For the forks, I don't think you can just overwrite the images. We might have to introduce a variable for the OWNER to provide repo packages on your own fork otherwise the workflow will probably just fail. Is that what you meant by the question?

Yes.

[markusweigelt]

But what if I don't want to make build, but have make start pulling the prebuilt images?

Then the images are downloaded from the container repository and started. Please consider the image names in main repo are prefixed with ghcr.io/markusweigelt/kitodo-production-ocrd in module repo ghcr.io/markusweigelt or ghcr.io/bertsky.

So the paths are different (e.g. OCR-D Manager image name main repo ghcr.io/markusweigelt/kitodo-production-ocrd/ordc_manager:lastest to module repro ghcr.io/markusweigelt/ordc_manager:lastest). Because in our main repro kitodo-production-ocrd we possibly provide an older version of ocrd_manager but a working and tested one with the other modules. Do you find this excessive and confusing?

Yes, that's why I raised the point. (And I'm fine with switching to slub everywhere, but we would first have to transfer the repos, which I don't think we can do ourselves.)

For now, can we offer this as an interim version and then move the repositories in the next step when we have clarity? Currently we also provide the images under our GitHub name via Docker Hub but without automated creation.

[bertsky]

Then the images are downloaded from the container repository and started. Please consider the image names in main repo are prefixed with ghcr.io/markusweigelt/kitodo-production-ocrd in module repo ghcr.io/markusweigelt or ghcr.io/bertsky.

Ah, I did not even notice that before!

So the paths are different (e.g. OCR-D Manager image name main repo ghcr.io/markusweigelt/kitodo-production-ocrd/ordc_manager:lastest to module repro ghcr.io/markusweigelt/ordc_manager:lastest). Because in our main repro kitodo-production-ocrd we possibly provide an older version of ocrd_manager but a working and tested one with the other modules. Do you find this excessive and confusing?

Yes, quite so I'm afraid. I thought we would simply rely on the normal subtagging mechanism (latest vs release vs stable...) for that. I don't see the point in managing a distinct set of packages/images in the main repo. Hence, the owners of the images should exactly correspond to the owners of the respective submodules.

[markusweigelt]

Yes, quite so I'm afraid. I thought we would simply rely on the normal subtagging mechanism (latest vs release vs stable...) for that. I don't see the point in managing a distinct set of packages/images in the main repo. Hence, the owners of the images should exactly correspond to the owners of the respective submodules.

For our module repos it is not necessary except the Kitodo.Prodution cause on the one hand there is no offical image and at the other hand we need features/state of the ocrd-main branch of my fork. So i think there is no other place than provide the package in this repository.

For the rest I will delete the packages and rewrite the .env to the modules repros.

[markusweigelt]

Ok i can provide Kitodo.Production image on my fork too. What do you mean is the best variant?

[bertsky]

Ok i can provide Kitodo.Production image on my fork too. What do you mean is the best variant?

Yes, that's what I thought of. And since we point to that as our submodule, it's also the most natural.

[markusweigelt]

Invalid due to this pull request. #49