-
-
Notifications
You must be signed in to change notification settings - Fork 668
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
rules_go upgrade from v0.18.6 => 0.19.4 results in stamping not expanding variables #2224
Comments
I took a quick look at this. I was initially able to reproduce the error, but as soon as I made any change at all, it would stop reproducing. Looking at
That seemed to prevent the stamp from happening. But when I made a change:
Here, the version got stamped with After I fetched tags, the script printed a version and I couldn't reproduce the issue anymore. Is it possible this is the issue you're seeing? If so, the link action probably just needs to be better at reading status files. |
Did you try invoking the workplace_status command? When I try it, I get
Which, I think, comes from As another datapoint, I think it is running approximately correctly on my corp box:
is the result after a blaze clean and build with --stamp. WDYT? |
A discovery: I created a trivial I suspect that the problem is the binary is built for the host platform and the stamp flag does not appear to be on in that configuration. |
I can confirm this is related. when I I will send in a PR with a failing test case for rules_go |
FWIW, I think the --stamp flag in bazel is not very well understood or documented (more on this in a previous comment). |
I wonder if we can do something about this issue without removing our reliance on the --stamp flag. The documentation for the --stamp flag says,
https://docs.bazel.build/versions/master/user-manual.html#flag--stamp |
Demonstrate that stamps are not compiled into objects when referred to through genrules.
Closing this issue. I assume Bazel's behavior of not stamping host binaries is WAI, but if not, it would be better to raise an issue there. |
What version of rules_go are you using?
Upgrading from
v0.18.6
tov0.19.4
n.b. that commit 37896e3 is not included in the
v0.18.6
release, but is in thev0.19.4
release so I think this is possibly user error from #2110, but I'm still confused.What version of Bazel are you using?
Does this issue reproduce with the latest releases of all the above?
Yes
What operating system and processor architecture are you using?
Linux amd64
Any other potentially useful information about your toolchain?
No additional toolchains.
What did you do?
Here is the difference https://github.com/bazelbuild/bazel-watcher/compare/master...achew22:v0.10.4?expand=1
To run this on your local box:
I'm explicitly passing
--stamp
and--workspace_status_command
which, when invoked withpython tools/workplace_status.py
prints out aSTABLE_GIT_VERSION
.What did you expect to see?
I expect to have the build succeed
What did you see instead?
I catch an assert statement in my code
The text was updated successfully, but these errors were encountered: