-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Allow Starlark rules to observe the --stamp
setting
#11164
Comments
This would be incredibly useful. All the rules in bazelbuild/rules_pkg need the capability to either use epoch based times in distribution archives (for reproduceibilty) OR to use the current time (for the release build). To get that behavior, we need it as a runtime flag, not a rule attribute. |
So, I found a work-around. You can define a If, like me, you want a private attr, then you can use a label attr and default to an |
configurabilty team looked at this. It might trigger some other feature changes we can do, but we are not planning to work on this issue right now, since there is a workaround. |
Also: #10907 |
What kind of feature changes? It seems straightforward to add a stamp field or method to the context, and I don't see any immediate issue with that. |
…1) (#288) Add stamp attribute to pkg_tar (in the style of cc_binary(stamp=-1,0,1) Part 1 of #287 This is not pretty, because Bazel does not make --stamp available directly - add a config setting to mimic --stamp: private_stamp_detect - This is a bit of a hack, until the value of stamp is available directly from starlark ctx See: bazelbuild/bazel#11164 - use the config setting to pass a bool down to the packaging rule to see that --stamp was set - add the stamp attribute to pkg_tar - use combination of stamp & private_stamp_detect to invoke stamping - this uses an undocumented feature to get to bazel-out/volatile-status.txt - that is bad in theory - In practice Bazel will eventually have admit the cat is out of the bag and document the files. Future work: - implement for all 4 package types. - contain a test where a stamped package is used from a workspace that includes rules_pkg. RELNOTES: Add stamp to pkg_tar.
It is possible to use a transition to read the command line option and let a provider pass the information back. See the
|
You can do this without a transition. Something like //my/BUILD
//some/rule.bzl
But this has the same limitation as your example - that we need an external helper to extract the time text from a file. What is missing for me is having the time stamp directly accessible from |
@aiuto Your solution with a single |
That is what I did for rules_pkg. What I don't like is that I need a
process run in an action to parse the status file. That either means some
sort of shell vs .bat script or a binary of some sort, then your rule may
have to depend on some language toolchain.
…On Thu, Dec 9, 2021 at 1:55 PM Fredrik Medley ***@***.***> wrote:
@aiuto <https://github.com/aiuto> Your solution with a single
config_setting is much simpler. I also prefer filtering stable-status.txt
before using the data to improve cache hit rate, so I never tend to be
dependent on using the stamp flag in rule implementations.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11164 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXHHHFLAYIA6T4PDJLQX7DUQD3RVANCNFSM4MMS7EVQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I just went through the same as aiuto for the Python rules; having to run another executable is w/e, but having to figure out the necessary shell to transform things was a pain. Plus, since I'm now relying on bash, that inevitably means e.g. Windows or other platforms without bash need more work. This would have been trivially easy and easily cross-platform if they were directly available to Starlark on ctx somewhere. That said, a couple tips for other who need to process these files:
Will basically give you an array with all the keys/values from the files in it.
|
We added a stamping feature to Aspect's bazel-lib which solves this problem in a nice, tidy way: |
It seems the issue is resolved with improved api @buildbreaker2021 is working on |
Description of the feature request:
As noted in a comment on #1054, Starlark rules can access
volatile-status.txt
asctx.version_file
andstable-status.txt
asctx.info_file
, but there is no way for a Starlark rule to observe the--stamp
flag setting to know if the rule should access the files or not.What underlying problem are you trying to solve with this feature?
I want to write Starlark rules that do not access the status files unless the user specifies the
--stamp
setting.Because of issues like #10075 and #10177 it is important that unstamped builds are shielded from any access to the status files:
stable-status.txt
even if you set your workspace status command to/bin/true
.no-remote-exec
on our stamped actions that accessvolatile-status.txt
, which is a bottleneck for remote builds.I tried using a custom build flag as a work-around to propagate my own version of the stamp setting, but it causes all outputs through transitions to change their output path and destroys all caching -- even on targets that don't depend on the new stamp-like setting.
What operating system are you running Bazel on?
macOS and Linux
What's the output of
bazel info release
?The text was updated successfully, but these errors were encountered: