4 ms·
Simplest answer is to release the code with a Dockerfile. Anyone can then inspect build steps, build the resulting image and run the experiments for themselves.
by dijksterhuis 6y ago
Simplest answer is to release the code with a Dockerfile. Anyone can then inspect build steps, build the resulting image and run the experiments for themselves.
Two major issues I can see are old dependencies (pin your versions!) and out of support/no longer available binaries etc.
In which case, welcome to the world of long term support. It's a PITA.
- OnlyOneCannolo 6y agoYou can also save the image to a file: https://docs.docker.com/engine/reference/commandline/image_save/ https://docs.docker.com/engine/reference/commandline/image_s...
- atomi 6y agoI would recommend running a registry mirror as it's fairly straightforward. https://docs.docker.com/registry/recipes/mirror/ https://docs.docker.com/registry/recipes/mirror/
- OnlyOneCannolo 6y agoThat's still more effort than pushing a tar file to a free public gh repo.
- atomi 6y agoThere is a bit of upfront work, but backups are thereafter automated.
- OnlyOneCannolo 6y agoTrue. I was thinking more for archiving science. Most people in that category would probably rather push to gh or upload to Dropbox than set up a docker registry.
- Nullabillity 6y agoThat doesn't help against expiring base images though.. :/
- donmcronald 6y agoYeah. That’ll be a mess. The way I try to do it is to build an image for a project’s build environment and then use that to build the project. The build env image never changes and stays around forever or as long as is needed. So when you have to patch something that hasn’t been touched for 5 years you can build with the old image instead of doing a big update to the build config of the project. Many Docker based builds are not reproducible. Even something as simple as apt-get update failing with a zero exit code (it does this) adds complexity and most people don’t bother doing a deep dive. Personally I use Sonatype Nexus and keep everything important in my own registry. I don’t trust any free offerings unless they’re self hosted.
- tensor 6y agoThere needs to be a way to create a combined image of all dependencies to distribute with a Dockerfile and code. That way people could still modify the code and dockerfile.
- bananadonkey 6y agohttps://docs.docker.com/engine/reference/commandline/save/ https://docs.docker.com/engine/reference/commandline/save/ You already have the source, now you have a dist.
- AlphaSite 6y agoTern is designed to help with this sort of thing: https://github.com/tern-tools/tern#dockerfile-lock https://github.com/tern-tools/tern#dockerfile-lock It can take a Dockerfile and generate a 'locked' version, with dependencies frozen, so you at least get some reproducibility. Disclaimer work for VMware; but on a different team.
- globular-toast 6y agoThe Dockerfile should always be published, but it does not enable reproducible builds unless the author is very careful but even so there's no support built in. It would be cool if you could embed hashes into each layer of the Dockerfile, but in practice it's very hard to achieve.