Closed sbesson closed 3 years ago
This pull request has been mentioned on Image.sc Forum. There might be relevant details there:
Certainly makes sense though I have some concern about the use of "latest". Would it be worth creating the 5
tag? Probably not too important since we aren't planning a breaking change at the moment. But in terms of encouraging best-practice, latest
in the wild may come back to bite us ;)
(Sorry, hit the wrong button)
No objection to using the major versions rather than latest
from my side along the same line of arguments as the one you presented. Especially now the OMERO versioning is being increasingly semvery, this might prove to be the best compromise in terms of maintenance of these Docker compose files.
It should be straightforward to push a tag alias. Only other consideration if we go that route is we might need to adjust our script/template/workflows generating these Docker images to maintain the major version tag /cc @jburel
ome/omero-server:5
, ome/omero-web:5
and ome/omero-web-standalone:5
now pushed to the registry.
ome/omero-server:5
,ome/omero-web:5
andome/omero-web-standalone:5
now pushed to the registry.
Manually? Shall I update the Makefile?
Manually? Shall I update the Makefile?
Manually for now. I am happy to open a separate PR to update the Makefile of both repositories if we get a sign off on this proposal.
Going with number is in the spirit of the doc stable
vs latest
, thumbs up for proposal
Thanks both. Opened https://github.com/ome/omero-server-docker/pull/54 and https://github.com/ome/omero-web-docker/pull/58 to systematically produce these major version tags when a new image is built and pushed to the registry.
Without having a GHA to constantly bump this repo, I assume this is the best we can do in terms of getting the best to the user. (And even if we did have such a bot, that wouldn't update docker-compose files that users have already copied elsewhere. That would likely take dependabot understanding docker-compose.yml itself)
So :+1: for this PR, but brainstorming a bit before we move on:
docker-compose pull
?omero-server
to 5
as well?Continuing the brainstorming. It looks like we're converging
Worth a comment to tell users where to look for updates? (5-->6)
Do you mean in the README or as an interactive message?
Do our current release announcements properly capture the docker crowd? Do we need to explicitly tell them to run docker-compose pull?
The answer is probably no - see https://www.openmicroscopy.org/2021/03/17/omero-web-5.9.0.html for the last announcement. I think docker[-compose] pull
sounds like a good option in all cases to pick up rebuild, new version etc depending on the use case.
We don't have a reference location in the documentation that documents these images, right? In which cases, I'd probably argue for 1- the README of this repository (and similar ones), 2- maybe the announcements, 3- maybe the README of the Docker image repositories?
(When) Should we move omero-server to 5 as well?
I thought I had done that as part of this PR - pushed as 7d9bf7d
Do you mean in the README or as an interactive message?
I was thinking in the docker-compose itself.
I thought I had done that as part of this PR - pushed as 7d9bf7d
:+1:
I pushed an extra commit to update the README with the docker-compose pull
recommendation.
I'll add a comment to the Dockerfile about major versions and upgrade. What about something along the line
# This container use the tag for the latest release of OMERO 5
# To upgrade to the next major release, increment the major version number
or another suggestion?
Once pushed, I'd propose to get this in, apply the same changes to all Docker compose example repositories and capture follow-up todos in other repositories as GitHub issues
Sounds find (though needs one more s
)
40411b2 pushed (with the missing s
)
As noted on a recent forum post, the pinning of the OMERO.server and OMERO.web image to a minor version does no longer scale especially as the release cycle of OMERO.web is increasing and we want our default example to include the latest security fixes.
This PR proposes to use Docker Hub
latest
tag for both server and web base images. The advantage of this solution is to minimize our maintenance burden as we release new images. The downside is that it pushes the burden on an end-user to rundocker-compose pull
to get the latest versions of these images. An alternative would be to update dependencies as part of the DOcker images releases. Ideallydependabot
would be able to open a Pull Request but while Docker is supported as an ecosystem, I don't know whether it will deal with Docker Compose YML files - https://docs.github.com/en/code-security/supply-chain-security/about-dependabot-version-updates