On build error, the actual failure is drowned out by a lot of noise related to the build command #3890
Comments
|
Cc @linzhp I think that this is caused by your recent change. |
rickystewart
added a commit
to rickystewart/cockroach
that referenced
this issue
Mar 15, 2024
... to pull in `0e7e4e31aa49f1afbb402fbb4895f38bc702c88c`. See bazelbuild/rules_go#3890 This reverts a change in bazelbuild/rules_go#3824 which makes it much more difficult to see build errors. Epic: none Release note: None
craig bot
pushed a commit
to cockroachdb/cockroach
that referenced
this issue
Mar 15, 2024
120490: ui: show license expiration alert in Db Console r=koorosh a=koorosh With this change, new alert message is shown in Db Console when license is expired or less than 15 days left before it will expire. This change doesn't affect clusters that doesn't have any license set. Release note (ui change): show alert message in Db Console when license is expired or close to expire. Depends on: #120475 Resolves: #98589 Epic: None Screens: 1. Less than 15 days before license expires <img width="1215" alt="Screenshot 2024-03-14 at 13 26 18" src="https://github.com/cockroachdb/cockroach/assets/3106437/54f18792-d16f-43d1-a439-bd04e7a91abd"> 2. License expired <img width="1215" alt="Screenshot 2024-03-14 at 13 25 26" src="https://github.com/cockroachdb/cockroach/assets/3106437/ec9b924a-7800-4cf9-a164-9f4f5b49e91f"> 3. License expired today <img width="1215" alt="Screenshot 2024-03-14 at 13 25 59" src="https://github.com/cockroachdb/cockroach/assets/3106437/38a29b0d-47c3-447a-beb5-d557b58bcfc9"> 120505: sql: deflake TestTrackOnlyUserOpenTransactionsAndActiveStatements r=rafiss a=rafiss This changes the test to block in AfterExecute rather than OnTxnFinish, which should make the active statements assertion less flaky. It also fixes a testing bug where the SELECT FOR UPDATE was not in a txn. fixes #120042 fixes #120235 fixes #119829 Release note: None 120547: ccl/cliccl: avoid opening Engine in debug encryption-decrypt r=sumeerbhola a=jbowens Adapt the `debug encryption-decrypt` command to avoid actually opening the Engine and instead only open the filesystem environment. This allows the command to be used even when missing or corrupt files prevent the Engine from being opened. Epic: none Fix #96699. Release note: none 120562: build: update `rules_go` r=jlinder a=rickystewart ... to pull in `0e7e4e31aa49f1afbb402fbb4895f38bc702c88c`. See bazelbuild/rules_go#3890 This reverts a change in bazelbuild/rules_go#3824 which makes it much more difficult to see build errors. Epic: none Release note: None Co-authored-by: Andrii Vorobiov <and.vorobiov@gmail.com> Co-authored-by: Rafi Shamim <rafi@cockroachlabs.com> Co-authored-by: Jackson Owens <jackson@cockroachlabs.com> Co-authored-by: Ricky Stewart <ricky@cockroachlabs.com>
|
Yeah, I realized that too. Let's revert it then. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of rules_go are you using?
0.46
What version of gazelle are you using?
v0.33.0
What version of Bazel are you using?
6.2.1
Does this issue reproduce with the latest releases of all the above?
I haven't tried with the very latest version of Gazelle and Bazel, though I don't see why doing so would fix it.
What operating system and processor architecture are you using?
macOS/arm64
Any other potentially useful information about your toolchain?
No
What did you do?
Run a build of a failing target (i.e., insert a compile error like a line of gibberish into a
.gofile)What did you expect to see?
Using v0.43 of
rules_go, if I build a failing target, I get a relatively terse failure like the following:The entire message output is quite short, and the actual error (
pkg/cmd/dev/build.go:129:2: undefined: sdfdsfsdf) is quite close to the end of the output, making it trivial to spot when you're iterating.What did you see instead?
Using v0.46, the error message for a similar failure looks like this:
This time, I need to scroll up before I can see the actual error. (Note that this looks more readable in the GitHub output than in the terminal, as a terminal usually does not allow you to scroll right and left and instead wraps the extremely long final line.) This is a relatively small, simple Go package, so consider that it will be far more unreadable for a large production codebase.
If I wanted to see the command-line, I had the option of running the build with
-sor--verbose_failures-- I find it dubious that most developers will want to see all this. My hunch is for the large majority of developers, this is irrelevant noise, which makes me think it should not be there in the output. What is actually desired for developers is the compiler error message, which is obscured. Given these command-line options exist and are opt-in (as they should be), my feeling is that #3824 should be reverted. However, if the command is going to be there, it would be much better if the actual compile error (in this case:pkg/cmd/dev/build.go:148:2: undefined: asldkfjsf) were at the bottom, so it is the first thing you see (as in v0.43).The text was updated successfully, but these errors were encountered: