-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Propagate the full workspace status info to cc_library linkstamp. #13877
base: master
Are you sure you want to change the base?
Conversation
Minimal patch to fix bazelbuild#1992 and bazelbuild#4863. Includes both predefined and custom keys as build information for C++ stamping, treating all unknown keys as strings. Makes it so that the build-info will be redacted iif both volatile and non-volatile info is requested in a single header, since the inputs are now always passed in to figure out the available keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@oquenchil Thank you for your review. |
Sorry, this causes 2 internal tests to fail. When I have time I will fix them and merge. |
Let me copy paste what the errors are and the tests themselves, perhaps you can take a look:
|
@oquenchil The main issue with these tests is that they rely on the current assumption that passing an empty input set should result in redacted information being generated. With this patch, this assumption is no longer true, since we now need to account for custom variables as well, so we need access to As a consequence, to infer whether the build info should be "redacted", we now rely on the request for both volatile and non-volatile info at the same time. Previously, this was only allowed when inputs were empty (which meant "redacted"), now I made it so that it is itself the trigger for "redacted". The downside is that you can't request for stable-only or volatile-only redacted information. This was meant to keep the existing method signature by also preserving an invariant that seemed to hold true throughout the public code, but please let me know if you think we need an explicit "redacted" flag to be passed in or a different way to infer the "redacted" status (rather than hijacking the existing flags). Assuming we keep the "redacted" inference as per this PR, we can fix the tests by always providing non-empty input artifacts and asserting redacted only when we pass in both Simply allowing empty input sets (as before) is also an option, just to account for these tests. But I find it dangerous/confusing, as it would silently still allow generating just the predefined variables as redacted build info. What do you think? |
Hey, IIUC the issues you linked would be fixed if users had their say in generating BuildInfo files. |
Hi, any update on merging this? I just ran into the same issue :( |
Minimal patch to fix #1992 and #4863.
Includes both predefined and custom keys as build information
for C++ stamping, treating all unknown keys as strings.
Makes it so that the build-info will be redacted iif both
volatile and non-volatile info is requested in a single header,
since the inputs are now always passed in to figure out the
available keys.
Closes #1992.
Closes #4863.