Add patch_tool argument to npm_translate_lock

[MichaelMitchell-at]

We encountered a bug with MacOS's implementation with patch, likely due to it being based on an ancient version of patch.

$ patch --version
patch 2.0-12u11-Apple

One downstream effect of patch being broken locally is that it leads to remote cache misses since our remote cache warming machines are using a non-broken implementation of patch.

This PR adds support for specifying a custom patch tool so that we can use a non-broken implementation.

Changes are visible to end-users: yes

• Searched for relevant documentation and updated as needed: no
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: no

Test plan

Manual testing; please provide instructions so we can reproduce:

• Add the following to MODULE.bazel:

http_file(
    name = "patch",
    executable = True,
    integrity = "sha256-0RgbIckQNYDwdh4kyrCgStgN3Dqj8XnnvIwOMJRRoks=",
    url = "https://cosmo.zip/pub/cosmos/bin/patch",
)

• Pass the following argument to npm.npm_translate_lock

    patch_tool = "@patch//file:downloaded",

[CLAassistant]

All committers have signed the CLA.

[aspect-workflows]

Test

All tests were cache hits

212 tests (100.0%) were fully cached saving 34s.

---

Test

e2e/bzlmod

All tests were cache hits

5 tests (100.0%) were fully cached saving 857ms.

---

Test

e2e/gyp_no_install_script

All tests were cache hits

2 tests (100.0%) were fully cached saving 503ms.

---

Test

e2e/js_image_oci

All tests were cache hits

1 test (100.0%) was fully cached saving 7s.

---

Test

e2e/npm_link_package

All tests were cache hits

3 tests (100.0%) were fully cached saving 820ms.

---

Test

e2e/npm_link_package-esm

All tests were cache hits

3 tests (100.0%) were fully cached saving 1s.

---

Test

e2e/npm_translate_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 34ms.

---

Test

e2e/npm_translate_lock_empty

All tests were cache hits

1 test (100.0%) was fully cached saving 34ms.

---

Test

e2e/npm_translate_lock_multi

All tests were cache hits

2 tests (100.0%) were fully cached saving 171ms.

---

Test

e2e/npm_translate_lock_partial_clone

All tests were cache hits

1 test (100.0%) was fully cached saving 129ms.

---

Test

e2e/npm_translate_lock_replace_packages

All tests were cache hits

3 tests (100.0%) were fully cached saving 503ms.

---

Test

e2e/npm_translate_lock_subdir_patch

All tests were cache hits

1 test (100.0%) was fully cached saving 222ms.

---

Test

e2e/npm_translate_package_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 131ms.

---

Test

e2e/npm_translate_yarn_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 131ms.

---

Test

e2e/package_json_module

All tests were cache hits

1 test (100.0%) was fully cached saving 590ms.

---

Test

e2e/pnpm_lockfiles

All tests were cache hits

40 tests (100.0%) were fully cached saving 3s.

---

Test

e2e/pnpm_workspace

All tests were cache hits

10 tests (100.0%) were fully cached saving 3s.

---

Test

e2e/pnpm_workspace_rerooted

All tests were cache hits

12 tests (100.0%) were fully cached saving 2s.

---

Test

e2e/repo_mapping

All tests were cache hits

2 tests (100.0%) were fully cached saving 474ms.

---

Test

e2e/rules_foo

All tests were cache hits

2 tests (100.0%) were fully cached saving 470ms.

---

Test

e2e/runfiles

All tests were cache hits

1 test (100.0%) was fully cached saving 474ms.

---

Test

e2e/vendored_node

All tests were cache hits

1 test (100.0%) was fully cached saving 199ms.

---

Buildifier      Format

[alexeagle]

thanks!

[alexeagle]

we should consider ALWAYS using a hermetic patch implementation. I recall we looked into the one Bazel itself uses, but it wasn't exposed for repository rules to use? Maybe @gregmagolan remembers. Can be in a later PR though.

[alexeagle]

Hm, I don't understand why this isn't triggering our GitHub Actions CI. Is it rebased on a really old base commit?

[MichaelMitchell-at]

Hm, I don't understand why this isn't triggering our GitHub Actions CI. Is it rebased on a really old base commit?

Oh right. I had this on top of v2.1.0 which is what we're still currently using. Let me rebase.