This has be a distinct flag. In #155 we determined that preserve mtimes of files in included tarballs. will not break repeatable builts. Using the mtime of files has reproducibility problems.

My first path of action and still my preference would be to make this able to use the build stamp vars and the mtime arg, but I found that there wasn't really a straightforward way to get those from the bazel API for .bzl files without parsing out the stamp files myself. Perhaps I just didn't look in the right place. Also, the current usage of the mtime arg is only applied to the overall tar file's time, not the files inside.

That is certainly different than what this PR does. What if there was a magical syntax like mtime = "VOLATILE_BUILD_TIME"?
This would make the target non-reproducible, because every time you build you would get a new result. OTOH, that might be what you want.

That is certainly different than what this PR does. What if there was a magical syntax like mtime = "VOLATILE_BUILD_TIME"?

Isn't that one of the purposes for the existing build stamping in Bazel, e.g. with BUILD_TIMESTAMP?

This would make the target non-reproducible, because every time you build you would get a new result. OTOH, that might be what you want.

Reproducible in the exact down to the byte form is not required. The main thing needed is for the files served via http from the new image should be the same or newer timestamps compared to the previously built and deployed image so the last-modified and etag headers are useful.