Changes verbosity of msbuild from quiet to normal in the appveyor script #16505

pull sipsorcery wants to merge 1 commits into bitcoin:master from sipsorcery:appveyor_verbosity changing 1 files +1 −1

sipsorcery commented at 8:03 AM on July 31, 2019: member

Increasing the verbosity helps to identify the cause of build errors which is the main purpose of the appveyor script.

Partially in response to #16487 where the msbuild error is difficult to determine due to the quiet logging level.
Changes the verbosity of msbuild from quiet to normal in the appveyor script. Increasing the verbosity helps to identify the cause of build errors which is the main purpose of the appveyor script. 0646ca5ea2
fanquake added the label Tests on Jul 31, 2019
fanquake added the label Windows on Jul 31, 2019
practicalswift commented at 8:13 AM on July 31, 2019: contributor

utACK 0646ca5ea2541d4da324d9aff7de422c6daa0ef9
laanwj commented at 8:29 AM on July 31, 2019: member
Generally for the CI builds we want:
- low verbosity/spammyness when there are no errors, when things are as expected
- highest possible verbosity for errors
if this helps debugging errors: concept ACK
sipsorcery commented at 8:39 AM on July 31, 2019: member
I tested the msbuild verbosity levels of quiet, minimal and normal in the context of getting useful information when a build error occurs. At levels below normal there's a lot of useful information missing. It does mean a lot of extra log messages for every build but since I suspect they are ignored unless there is an error it seems a reasonable sacrifice.

For reference the msbuild verbosity levels are:
```
  /verbosity:<level> Display this amount of information in the event log.
                     The available verbosity levels are: q[uiet], m[inimal],
                     n[ormal], d[etailed], and diag[nostic]. (Short form: /v)
                     Example:
                       /verbosity:quiet
```
fanquake commented at 10:10 AM on July 31, 2019: member

Concept ACK
laanwj commented at 10:10 AM on July 31, 2019: member

since I suspect they are ignored unless there is an error it seems a reasonable sacrifice

Yes, the only reason I'm saying this is because Travis log viewing becomes really slow on large log files, so when an actual problem happens it can be frustrating to have to scroll through screenfulls of 'normal build output' to finally get to the thing that actually caused the error.

MarcoFalke commented at 11:24 AM on July 31, 2019: member

ACK 0646ca5ea2541d4da324d9aff7de422c6daa0ef9. Previously I had to ping sipsorcery every time an issue appeared, now I might be able to look it up myself.

<details><summary>Show signature and timestamp</summary>

Signature:

Timestamp of file with hash 13fc30792d1a6d38adadc3527511e36b544dc0e39e4acc79faec05819b86439e -

</details>

MarcoFalke referenced this in commit f89113626e on Jul 31, 2019
MarcoFalke merged this on Jul 31, 2019
MarcoFalke closed this on Jul 31, 2019
MarcoFalke commented at 12:45 PM on July 31, 2019: member

Would be nice if it was possible to write everything to a log and only print the log on failure (similar to our test_runner), but that can be done in a follow up, if needed.
DrahtBot locked this on Dec 16, 2021

Contributors

Labels

Linked (view graph)

#16487 validationinterface: add unused CChainState parameter