5 ms·
We have used reproducible builds for many years, and we haven't had issues with it. Of course you're going to get random results when you issue random commands
by oneplane 3y ago
We have used reproducible builds for many years, and we haven't had issues with it. Of course you're going to get random results when you issue random commands (like apt-get install), which is why you don't do that if you want reproducible builds.
It's also not a normal workflow to build the same image many times, except for validation, and you do that with frozen sources, not arbitrary references. You build the image, sign it, distribute it. It doesn't get rebuilt on the destination.
- kreetx 3y agoHow do you do reproducible builds at the moment?
- oneplane 3y agoWe build on official releases and add our own artefacts. So we might pin to a microsoft dotnet hash, a JVM hash, a nodejs hash, and in our pipeline add a released application to that container. There are no packages installed, only files added, including an entry point. This is then signed and stored, along with the source commit and source image. This way we can reproduce at will, but also make use of the very large ecosystem of suppliers, consultants and communities that already exist. Edit: the other resources (source, source image) are also packaged as OCI images and signed and stored so you have everything available in the registry, even if the source repositories were to cease to exist. Because everything else we run interfaces with OCI registries by default we don't have to re-invent that wheel.
- kreetx 3y agoReproducible build means that you get your source code from somewhere, it has dependencies listed, you install those, then you compile your artifact from your source, and the resulting binary or container is always the same. You can delete them, start from source in six months and it will still be the same. If you want to do that, you'd need to keep your artifact around, and I guess you'd also need to back up the docker images you depend on.