Closed markusweigelt closed 1 year ago
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?
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, theOWNER
can only be an organization or a user. For organization repositories we need to have access to one suitable for examplehttps://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.
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.
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 repoghcr.io/markusweigelt
orghcr.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 reproghcr.io/markusweigelt/ordc_manager:lastest
). Because in our main reprokitodo-production-ocrd
we possibly provide an older version ofocrd_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.
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.
Ok i can provide Kitodo.Production
image on my fork too. What do you mean is the best variant?
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.
Invalid due to this pull request. #49
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 usebertsky
here (deviating from the repo).