You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My issue is similar to #180. The difference is that it does not happen when the workspace is different, it happens when the host machine is different.
For commit with SHA: abcdef
Hashes generated on a local machine match, even when we try 2 different workspace paths, for example /a and /b, which contain a separate clone of the same repo.
For the same commit, hashes generated on a Jenkins node are different. Jenkins of course has a different workspace path than the local machine.
This should not be an issue if we cache the hashes from the Jenkins pipeline and reuse them inside Jenkins only, but our use case tries to generate these hashes on the developer's machine if there is a cache miss (which is intentional for now).
Like the comment on that issue, if we do --ignoredRuleHashingAttributes=location,path, this solves the problem and hashes match, but my concern is can this have unexpected consequences like false positives or negatives and missing to detect some changed targets?
I am sorry if this is not a bazel-diff issue and more of a question related to the usage. I am new to Bazel and have inherited a code that uses it extensively. I could not find any doc about the impact of ignoring the location & path attributes.
We use bazel-diff 6.1.0 and bazel 6.5.0
The text was updated successfully, but these errors were encountered:
@tinder-maxwellelliott
I understand that using --ignoredRuleHashingAttributes isn't an issue by itself. However, I haven't explored how Bazel-diff utilizes attributes when calculating the hash. My question is: if we ignore location and path, could this lead to any false positives or negatives?
Apologies if this is a basic question, especially since you're not familiar with our environment. We do have some genrule like the one below that uses location. If you're unable to provide an answer, please feel free to close this issue.
My issue is similar to #180. The difference is that it does not happen when the workspace is different, it happens when the host machine is different.
For commit with SHA:
abcdef
Hashes generated on a local machine match, even when we try 2 different workspace paths, for example
/a
and/b
, which contain a separate clone of the same repo.For the same commit, hashes generated on a Jenkins node are different. Jenkins of course has a different workspace path than the local machine.
This should not be an issue if we cache the hashes from the Jenkins pipeline and reuse them inside Jenkins only, but our use case tries to generate these hashes on the developer's machine if there is a cache miss (which is intentional for now).
Like the comment on that issue, if we do
--ignoredRuleHashingAttributes=location,path
, this solves the problem and hashes match, but my concern is can this have unexpected consequences like false positives or negatives and missing to detect some changed targets?I am sorry if this is not a bazel-diff issue and more of a question related to the usage. I am new to Bazel and have inherited a code that uses it extensively. I could not find any doc about the impact of ignoring the
location
&path
attributes.We use bazel-diff 6.1.0 and bazel 6.5.0
The text was updated successfully, but these errors were encountered: