CODESIGN2
Tags missing from Docker Hub
Hi, first off thank you for setting this container and publishing it. We were pinning to the tag 1632011321 in https://github.com/humanmade/altis-local-server but all tags except for latest appear to have disappeared.
It'd be great to keep a stable tag of some kind if you're open to it, I've been burned by using latest multiple times in the past. Appreciate if it's not something you want to do as I understand these tools tend to be for internal use first.
Hello 👋 thanks for letting me know you use this.
I Believe checking that with a timestamp, it's September 2021 I set this up so that I can trigger builds, so with a slight tweak to the CI, it should be easy enough to re-publish (although that image may have CVE's)
Would you be able to please firstly check if there are any breakages in latest? What you have I think is a CI build, which should not be relied upon without a specific, named or versioned tag.
If you have a copy anywhere locally, you can also docker tag, and push to your own repository on DockerHub or elsewhere. I Find this to be the most stable way to use Docker, but again, if there is an issue with latest or you need that tag pushed again, I'm happy to see about re-building it.
I've pushed the tag and can confirm it was built with go 1.14. Besides the golang version there should be no differences with latest, this should unblock you. I'll check the image for vulnerabilities and get back to you.
Vulnerability scan says clean... Nice
lewiscowles@Lewiss-Mac-Studio ~ % docker scan cd2team/mailhog:1632011321
Testing cd2team/mailhog:1632011321...
Package manager: apk
Project name: docker-image|cd2team/mailhog
Docker image: cd2team/mailhog:1632011321
Platform: linux/arm64
✔ Tested 14 dependencies for known vulnerabilities, no vulnerable paths found.
For more free scans that keep your images secure, sign up to Snyk at https://dockr.ly/3ePqVcp
Amazing, thanks for responding so quickly and sorting the tags out, I’ll switch over to that tomorrow. Latest was working fine so no issues there, it was just preventing folks from spinning up the dev environment which we also use to run tests and needed a quick fix. Thanks again!
I had a similar problem with 1633825801. I have now switched to 1656201716.
Was there a reason why all the old tags were deleted? Just asking to understand if this could happen again in the future.
Images tagged only by date will again be removed in the future. This is mostly to prevent security breaches. Even when MailHog source code remains the same, re-compiling in a newer golang toolchain can mitigate security.
One potential workaround for this is to pull and re-tag, then push to an image repository you control. Is this something you might feel more comfortable doing?
One potential workaround for this is to pull and re-tag, then push to an image repository you control. Is this something you might feel more comfortable doing?
I suppose so. I would need to figure out how best to do it.
Is there a reason to create tags based on the date instead of based on the dependencies?
All those tags are from automated runs. There are many benefits to automated build, tag, deploy, but the one I'm most interested in is visibility. Knowing when something breaks, why and being able to see it gets fixed.
Stability of time tagged commits, felt to me to be implicitly throwaway. I'm learning new things about this through this conversation. Thank you all for sharing with me, so that I Can gain a better understanding of the thought-processes and needs around this.
I Personally pull from latest with this image, which is why I did not set-up more involved tagging, but I'm open to PR's and ideas around a more preferred approach to tags, as well as PR's for guard-rails. I've been quite lucky that mailhog is a mature, stable project, built around common standards, which won't change much, like SMTP, HTTP.
It is now possible to manually trigger builds from a branch, where you can specify a revision, tag or commit (I believe this is how go install package@{version} works)
This should make it even easier to fork this repo and run your own reproducible builds, and for me to mitigate de-tagging in the future. Please react 👍 for happy with this 👎 if you don't like it; or with 😕 if you are not sure. If you are not sure, please also comment.
Same thing, but now I can specify the tag (the way I branch name seems incompatible with docker-hub)
Thanks Lewis, for your responses. After discussing it with the team, we have decided that we will just use the latest tag as this risk for this project is quite low.