Make patching API public #4318
Open
Make patching API public #4318
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Mar 28, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.java_bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=cme/clients/flipr-java-client/flipr-client tools/bazel build //cme/clients/flipr-java-client/flipr-client:src_main ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Mar 28, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Mar 29, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Mar 30, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Mar 30, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Apr 23, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Apr 23, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
raviagarwal7
pushed a commit
to uber-common/bazel
that referenced
this pull request
Apr 23, 2024
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
|
@cushon this change is being successfully used at Uber to enable Error Prone auto-patching to work with Bazel, along with bazelbuild/bazel#21640. I have a follow-on Error Prone fix that makes auto-patching also work for plug-in checks, which I'm happy to contribute as a PR as well (though it makes more sense to land after this one). Independent of the Bazel change, this PR seems straightforward and could be helpful for any build system trying to integrate Error Prone. So, it'd be great if someone from the EP team could review it sometime. Thanks! |
cushon
reviewed
May 3, 2024
| .customRefactorer() | ||
| .or( | ||
| () -> { | ||
| ScannerSupplier toUse = |
There was a problem hiding this comment.
Yes, was an oversight, re-pushed the changes using the latest code.
rsalvador
force-pushed
the
make-patching-api-public
branch
from
6036b81
to
905d626
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
to be used by bazel’s error prone plugin: bazelbuild/bazel#21640