-
Notifications
You must be signed in to change notification settings - Fork 691
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
Base stamping decisions on --stamp configuration, not attributes on t… #1878
Conversation
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.
Could we add an update to README.md that explains this behavior?
e9ff310
to
4ccc7a5
Compare
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.
I think this is good but as we discussed we should wait for a major version change whenever we're ready.
The first option is to use stamping. Stamping is enabled when a supported | ||
attribute contains a python format placeholder (e.g. `{BUILD_USER}`). | ||
The first option is to use stamping. | ||
Stamping is enabled when bazel is run with `--stamp`. |
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.
Can this be configured with .bazelrc? I know some users want to always stamp containers so showing them an easy to use setup to make that always happen is probably a good idea.
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.
Updated this to still have a stamp
attribute on our three stamp-aware rules, and that attribute is now a trinary. So you can still use stamp=always behavior like before.
Okay so what's our cadence for major releases? |
Sounds good. I can luck off a 1.0 on Monday if you're ok with that? Let's
also check in with pcj but in my opinion this is fine.
…On Sat, Jun 5, 2021, 4:13 PM Alex Eagle ***@***.***> wrote:
Okay so what's our cadence for major releases?
Since we haven't released a 1.0 semver dictates that breaking changes are
in every minor. So we don't have a way to signal this beyond either just a
0.18.0 including this change.
I think we should have a 1.0. Could discuss doing that now? holding this
change for that doesn't make a difference for semver though
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1878 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG4HW6MZ47WTRL4OCC6NVLTRKAP7ANCNFSM457LHFEQ>
.
|
If we do 1.0 we need to say what that means and how we'll version in the future. Can discuss at our meeting Monday but I'll have to duck out early due to conflict |
5eb0478
to
cfcff81
Compare
This follows the example of rules_go and rules_nodejs. It means we don't produce cache-busting outputs unless the user explicitly requests non-deteriminism in the build with --stamp. BREAKING CHANGE: - To get stamped outputs, users must now call bazel with `--stamp` - the stamp attribute is removed from some providers - the stamp attribute is now trinary Fixes bazelbuild#1451
fyi @aptenodytes-forsteri rebased and landable. |
…he rule
This follows the example of rules_go and rules_nodejs.
It means we don't produce cache-busting outputs unless the user
explicitly requests non-deteriminism in the build with --stamp.
BREAKING CHANGE:
--stamp
replacement
Fixes #1451