-
-
Notifications
You must be signed in to change notification settings - Fork 152
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
oci_tarball does not produce consistent tars for the same inputs #328
Comments
if its okay to use rules_pkg I can probably work on fixing this up |
as a hack I worked around this by using
|
This is a known issue. We don't want a direct dependency on rules_pkg. See #217 |
Could we just add |
Sent PRs #380 (already merged) and #381. Here I simply tried adding parameters for How it could be done:
At least that would be my plan to do this, and I wasn't sure about some technical details here (e.g. how to set up a temp dir where we can extract the blobs and the manifest and then how to use that temp dir to call the build_tar tool). For now settled on not doing this refactor, but simply fixing the parameters, just leaving here these notes if it would be usable for anyone. |
your PRs have a bunch of gnu specific usages...I don't think this is as easy as just settings some flags, you'll need to do feature detection or something to figure out if you can use the flags... an easier approach would be to use rules_go and create a simple binary to tar the files...go stdlib has a tar implementation that is pretty straightforward to use...but then we need rules_go, or use go generate multiarch binaries as part of the release process and package them in rules_oci |
We are getting close on bazel-contrib/bazel-lib#468 so that will be the answer, we'll have a hermetic tar program available. |
Can we do anything other than waiting for the hermetic tar implementation? Should I maybe go with feature detection, to re-enable this for non-Mac systems for now? |
hermetic tar toolchain is now released in bazel-lib 2.0.0-beta0 |
I believe we should just wait for the hermetic toolchain. That said if you are relying on oci_tarball to be hermetic, that suggests that you are using it outside of its intended use. oci_tarball never intended to be anything other than, to make this image docker loadable. it should never be an input to other targets. just out of curiosity, what is your use case here? |
at snap we don't push images to registries during a build, users are expected to generate a tar which will get pushed to the right place for you, as such our bazel builds need to generate an image tar |
We are running integration tests where the image tar is an input. We also have unit tests, but these integration tests are critical to check whether the image configuration, packaging, static file content, etc. are intact. This is also checking integration between our own components. |
For anyone interested, #385 seems to be fixing this issue. |
Not sure whether I should report in this issue, so please let me know if it is worth opening a dedicated one. The |
Fixes #328 fix: supply mtree file for determinism fix: set tar content times to beginning of this year avoids some tools thinking that 1970 is 'too old' refactor: extract function for mtree lines refactor: cleanup STAGING_DIR chore: bump to bazel-lib 2.0rc chore: remove bazel 5 workaround Bazel-lib 2.0 doesn't include this anymore chore: upgrade stardoc to match bzlmod version ci: test on bazel 7 rather than 5
Fixes #328 fix: supply mtree file for determinism fix: set tar content times to beginning of this year avoids some tools thinking that 1970 is 'too old' refactor: extract function for mtree lines refactor: cleanup STAGING_DIR chore: bump to bazel-lib 2.0rc chore: remove bazel 5 workaround Bazel-lib 2.0 doesn't include this anymore chore: upgrade stardoc to match bzlmod version ci: test on bazel 7 rather than 5
fixed by #385 |
tarballs generated with oci_tarball keep username and unstable timestamps making oci_tarballs not consistent
The text was updated successfully, but these errors were encountered: