Extract proguard logic to new rules#29641
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
The only test failure is an exec format error only on windows/arm64 (windows/x64 passes): This is pretty surprising: is there a misconfiguration with the windows/arm64 jdk? |
|
Hmm, adding a @meteorcloudy , any ideas what's wrong here? |
|
I'm also tempted to rewrite this as a python script, which would probably also fix the windows issue. I'll think about it and get back to this later. |
jar instead of nonhermetic unzip|
Went ahead and used the script, and added actual rules, and re-arranged things somewhat. PTAL. |
- Timestamp clearing now uses a small hermetic python script instead of relying on non-hermetic `unzip` and `zip`. - Also split proguard and timestamp update actions for better caching. - Moved fastutil proguard spec into third_party where it is used. RELNOTES: None.
|
All tests fixed, hooray. |
| executable = ctx.executable._proguard_bin, | ||
| arguments = [ | ||
| "-injars", | ||
| ",".join([src.path for src in ctx.files.srcs]), |
There was a problem hiding this comment.
Even though this is just a rule for Bazel's internal use, it would be great if we could follow best practices and use Args instead. Folks (and AI) like to copy 😉
| ) | ||
|
|
||
| def _fix_timestamps(ctx, input, output): | ||
| ctx.actions.run( |
There was a problem hiding this comment.
Running this as a separate action means that the previous one will have non-deterministic outputs. Perhaps the two should be merged?
unzipandzip.RELNOTES: None.