-
Notifications
You must be signed in to change notification settings - Fork 136
Dependency on volatile-status.txt breaks remote cache #536
Comments
I found that depending on the |
General best practice here is to avoid stamping -- stamping is by definition volatile. Another practice we use over in kubernetes/test-infra is to separate out the stamp layer into its own final layer. AKA instead of making the final stamped layer include a large go binary in it, we put this into an intermediary layer. In other words instead of using the rules_docker container_image directly we wrap this into a prow_image macro which separates out the stamped layer from the large binary layer. This way 99% of the image layers remain reproducible (and therefore cached) and just the tiny final layer with stamp info changes between builds (assuming the image hasn't changed) |
@mariusgrigoriu and @fejta I created #592 as another attempt at addressing this issue. It exposes the |
That looks like a creative solution! We've settled into adding the I think the PR might simplify things a bit so we can just have the |
Found a use case where depending on the |
Just tested PR #592. I wasn't able to find a way to include only the stable status file as I don't know what the label for the generated |
@mariusgrigoriu I am using the following approach, which concatenates and filters out values from stable-status and volatile-status:
All the best! |
The above example helps a lot. I think this works good enough. What do you think about including |
The Bazel docs state:
However, that is untrue when it comes to the remote cache.
Our CI environment runs e2e tests that depend on a
k8s_object
on every run even when there are no changes due to the interaction between rules_k8s, stamping, and the remote_cache.I'd like to propose dropping the dependency on the volatile file, while retaining the stable file, or at least making it optional as a workaround since the Bazel maintainers are pushing back on fixing the underlying issue.
The text was updated successfully, but these errors were encountered: