-
-
Notifications
You must be signed in to change notification settings - Fork 866
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
[Bug]: Docker tag :latest points to nightly builds #3996
Comments
just looking at https://hub.docker.com/r/dessalines/lemmy/tags i don't think this is from the nightly task, as currently the latest tag is from 2 days ago while dev is only 20 hours old. |
This comment was marked as outdated.
This comment was marked as outdated.
|
it appears to actually be published by the this would also fall in line with the woodpecker docker plugin issue you linked, as it does indeed use i am however confused by the documentation, as the documentation states the following for
i read this as adding the a workaround would likely be to set |
oh well, i misread the issue you linked. https://codeberg.org/woodpecker-plugins/docker-buildx/issues/49 is the issue asking to add an option to not add the this behavior is indeed by design. the other issue, https://codeberg.org/woodpecker-plugins/docker-buildx/issues/53, is precisely about the workaround i was suggesting above not working, as the |
Hmm then we should push to Or we get rid of |
it might be an option to have conditional logic in the CI job to change behavior depending on the tag. for example, you could enable when using this approach it should be kept in mind that you'd never want to tag a release like 0.18.5 after a newer minor version, such as 0.19.0 was tagged, as otherwise the latest tag would be downgraded from 0.19.0 to 0.18.5 at that point. |
@Nothing4You I've looked into the woodpecker docs and it seems that the Another option would be to use Github actions for deploying the latest build to docker. You can use an There are still some other considerations here, i.e. it should be ensured that when a minor version gets applied to the previous major release after a new major release is out (for example |
something like this would probably work: publish_release_docker_latest:
# [...]
settings:
auto_tag: true
# [...]
when:
evaluate: 'CI_PIPELINE_EVENT == "tag" && CI_COMMIT_TAG matches "^[0-9]+\.[0-9]+\.[0-9]+$"'
publish_release_docker_unstable:
# [...]
settings:
auto_tag: false
tag: ${CI_COMMIT_TAG}
# [...]
when:
evaluate: 'CI_PIPELINE_EVENT == "tag" && not (CI_COMMIT_TAG matches "^[0-9]+\.[0-9]+\.[0-9]+$")' or one could try to fit it in the same job by setting if logic to avoid tagging latest for a lower version is to be added, this might make the process quite a bit more complex, as then you'd probably need to run a dedicated script to fetch versions from docker hub and compare version strings. |
thoughts on the approach above? should i draft a PR for that? |
Requirements
Summary
Various instance admins recently ran into problems after they accidentally upgraded to the
:latest
Docker tag. This shouldnt be a problem as latest is supposed to point to the most recent release version. But in fact it points to nightly builds from the development branch. This is not at all intended.Our Docker images are built and pushed by the woodpecker docker plugin. From my understanding of the documentation, our nightly build task should not push to the
:latest
tag. There is also an issue indicating that the:latest
tag is being pushed to incorrectly. So this seems like a bug. It would be very helpful if someone who is familiar with Go could look through the source code to find out how this can be resolved, so that:latest
tag only gets pushed for releases.The same problem is also happening for lemmy-ui.
The text was updated successfully, but these errors were encountered: