-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Over-triggering with rules_go and Gazelle under certain circumstances #83
Comments
Thank you for this great example repo. I will put together an integration test now in a draft PR |
Adds a new github action test to validate the issue reported in #83
Alright my PR above captures the issue |
Adds a new github action test to validate the issue reported in
Okay so here is the result of doing the diff manually, somehow all the external targets have changed
|
@mikberg is there any way to debug the BUILD files that are automatically created for go deps in a Gazelle project? Trying to understand how we are getting differences |
Hmm, you can at least |
This seems to also be impacting us, any debug info I can provide to help figure this out? |
I believe we are impacted as well because of this. |
Curious if #174 will solve this, might give it a try and see 👀 |
We are also running into this while trying to adopt bazel-diff. I looked into #174 and I don't think its quite right, since rules_go creates individual external repositories for each third party dependency. IIUC, #174 helps with situations where all external packages get put under one external repo namespace (eg I can confirm that a simple diff only touching WORKSPACE file produces a list of impacted targets that includes all external dependencies |
This issue is basically a better documented version of #70
Example repository: https://github.com/mikberg/bazel-diff-problem
This repository sets up rules_go with Gazelle, a go binary with an external dependency and some rule which depends on the WORKSPACE file. I think all three are important.
The second commit adds a comment to the WORKSPACE file, demonstrating that any change to WORKSPACE will now result in bazel-diff regarding all external Go dependencies as impacted. This presumably also is the reason why the
go_binary
is also regarded as impacted.I haven't been able to nail this down further.
As far as I can tell, this problem was introduced between 2.3.0 and 2.4.0.
Thank you for a fantastic tool!
The text was updated successfully, but these errors were encountered: