ci: change the build to be verbose by default #31619

1. 
   vasild commented at 5:24 pm on January 7, 2025: contributor

   Previously CI would use a non-verbose build (where exact compilation and linking commands are not visible) and only if it fails, would rerun the build in verbose mode.

   Change this to use verbose in the initial build as well for two reasons:

   1. It is useful to be able to see the exact compilation and linking commands even for successful builds, to e.g. confirm some particular flags are (not) used as expected.
   2. In failed builds, if the failure is during linking, the repeated verbose build may not show a single compilation command because all files are already compiled, so compilation flags will remain hidden.
2. ci: change the build to be verbose by default

   Previously CI would use a non-verbose build (where exact compilation
   and linking commands are not visible) and only if it fails, would
   rerun the build in verbose mode.
   
   Change this to use verbose in the initial build as well for two reasons:
   1. It is useful to be able to see the exact compilation and linking
      commands even for successful builds, to e.g. confirm some particular
      flags are (not) used as expected.
   2. In failed builds, if the failure is during linking, the repeated
      verbose build may not show a single compilation command because all
      files are already compiled, so compilation flags will remain hidden.

   01264fc4b6
3. 
   DrahtBot commented at 5:24 pm on January 7, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31619.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

4. DrahtBot added the label Tests on Jan 7, 2025
5. 
   vasild commented at 5:24 pm on January 7, 2025: contributor

   I actually needed this while working on https://github.com/bitcoin/bitcoin/pull/31424
6. 
   maflcko commented at 5:36 pm on January 7, 2025: member

   How is this different from just looking at the C++ compiler flags .................... output?
7. 
   theuni commented at 4:02 pm on January 8, 2025: member

   How is this different from just looking at the C++ compiler flags .................... output?

   Not weighing in on the approach here, but the flags output is fuzzy at best (see the disclaimer below them). Some flags only apply to certain types of objects (simd for ex), certain libs (leveldb), certain build types (shared/static), etc.

8. 
   maflcko commented at 4:17 pm on January 8, 2025: member

   Yes, it is a bit fuzzy, but printing the flags to the CI log doesn’t solve the problems listed in the motivation either, because to confirm that a flag is used for all compilations in a successful compilation, one will have to go through all lines. Without a script, I don’t see anyone doing that manually. In fact, this change makes the log so bloated that the scrollback will normally truncate it, so it is more likely that the change is going to hide issues instead of surface them.
9. DrahtBot added the label CI failed on Jan 11, 2025
10. 
    vasild commented at 9:09 am on January 13, 2025: contributor

    How is this different from just looking at the C++ compiler flags .................... output?

    The exact compilation command contains more information than just the flags. I guess this is why the second build (after a failure) is verbose. There is also this:

    0NOTE: The summary above may not exactly match the final applied build flags
    1      if any additional CMAKE_* or environment variables have been modified.
    2      To see the exact flags applied, build with the --verbose option.
    

11. DrahtBot removed the label CI failed on Jan 13, 2025
12. 
    maflcko commented at 11:31 am on January 16, 2025: member

    Yes, I understand they are not identical. As pointed out earlier, I don’t see how this solves this class of issues: #31619 (comment). It seems more like this is a one-off patch that was used once for debugging. I just don’t see how it could have helped in that case (as opposed to using already existing info in logs). It would help to add exact steps to reproduce your use-case, otherwise, this all seems a bit speculative.

Contributors
vasild DrahtBot maflcko theuni

Labels
Tests