-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Tag docker images with version and latest #1453
Comments
I am currently reworking the documentation in #1389 (almost done) which includes a proposed change in branches/release model. In the proposed model
Small example history graph: Advantages: simpler to maintain and understand, follows convention (the latest release is considered stable, development docker image is tagged latest. It scraps the "stable" tag wich was really the Disadvantages: users who previously used the I can update the tooling accordingly if @virtualtam and @ArthurHoaro are OK with the proposed changes. |
Yes that is excellent! Though I'm not sure how to prevent the breaking change you mentioned. 😞 |
A workaround in the meantime is to use the image digest. So to get the "latest" image, with version pinning, instead of: use: |
Following the merge of #1389, to enable what we discussed, we should do the following:
-> PR #1453 |
I don't understand the issue here, tag builds seem to be already available:
Yes, I am in the shaarli team but you don't seem to be. Do you want me to add you?
Good call. When we chose this terminology for our branches, we weren't aware that |
yes this is me
please
PEBKAC, docker tags based on semantic versioning tags are indeed working fine. |
- always set the target branch for update checks to `release` - update documentation (docker image tags, versioning, release procedure, README badges, migration) - doc: mention that the default-docker compose file uses the `:latest` image, update docker-compose documentation - rename the `:master` docker image tag to `:latest` - clarify method/variable names - fixes shaarli#1453
You should now have full access. |
- always set the target branch for update checks to `release` - update documentation (docker image tags, versioning, release procedure, README badges, migration) - doc: mention that the default-docker compose file uses the `:latest` image, update docker-compose documentation - rename the `:master` docker image tag to `:latest` - clarify method/variable names - fixes shaarli#1453
|
- push an image tagged :latest for builds on master - push an image with the same tag as the git tag for v*.*.* tags, and for the "release" branch - update documentation (remove references to Travis/Drone CI - deprecate stable and master Docker tags (ref. shaarli#1453) - add deprecation notices to CHANGELOG.md
- push images to https://hub.docker.com/r/shaarli/shaarli/tags using a personal access token (access tokens are not available for organizations) - push an image tagged :latest for builds on master - push an image with the same tag as the git tag for v*.*.* tags, and for the "release" branch - update documentation (remove references to Travis/Drone CI - deprecate stable and master Docker tags (ref. shaarli#1453) - add deprecation notices to CHANGELOG.md
- push images to https://hub.docker.com/r/shaarli/shaarli/tags using a personal access token (access tokens are not available for organizations) - push an image tagged :latest for builds on master - push an image with the same tag as the git tag for v*.*.* tags, and for the "release" branch - update documentation (remove references to Travis/Drone CI - deprecate stable and master Docker tags (ref. shaarli#1453) - add deprecation notices to CHANGELOG.md
Fixed and clarified in current
|
The latest image does not have a version tag. (I'm confused about the difference between the
latest
,master
andstable
branches, but in any case, they do not have version tags.)This is not standard practice, because you will always pull the latest version, and have no control over versioning. In most environments the infrastructure is tested in development, then tested in staging, then deployed to production. So one "pins" the version to be used, because one knows "it works". If we use
latest
(or master, stable, etc.), then it will pull a new version automatically, and it might break something. Pinning versions allows us to be sure what is deployed is 100% working as tested.So please consider doing this:
1.2.3
then the image should be tagged as1.2.3
as well as with thelatest
tag.latest
, because that is what docker will pull (whereas it looks like on docker hub the latest image is actually "master").Thanks!
The text was updated successfully, but these errors were encountered: