3 ms·

What often happens is you get a log like (contrived example): Warning: http timeout to package server 1 Warning: could not find x in package server 2

What often happens is you get a log like (contrived example): Warning: http timeout to package server 1 Warning: could not find x in package server 2 ..(several lines later).. Warning: could not find dependency x in cache .... Compile Error: unknown reference to "x" Because the actual problem by itself isn't fatal -- it doesn't yet know if the package is in server 2, and it might already have a suitable package in cache -- it's not a fatal error. Later, the part of the compiler they needs the dependency doesn't have context to the other failures that happened; all it knows is something is missing. This is a universal problem in almost every application: very rarely can a single log line provide enough information to fix a problem or identify a bug. In my contrived example, the partial fix is that the package bit should fail. However the final log message needs all the context of previous errors as well or it isn't useful either. It's turtles all the way down. It's not that this isn't a solvable problem, it's that people building compilers and other tools make assumptions about context, people putting together the build don't spend the time to learn the nuance of every tool they use (rightfully so - who had time for that?), and everyone falls back on the crutch of giant log files. In other words, through the whole stack (language, compiler, tools, build system, and individual application build itself), no one has optimized or built anything based on the idea the CI server or build system should have a single, useful error message.

marcosdumay 5y ago
The problem isn't the warnings and non-fatal errors. In fact, the largest problem is that the noise obscures them. The problem is the pages and pages of "did that, everything is fine". Since Linux distros stopped optimizing disk usage by omiting the update time of files a couple of decades ago, I haven't seen build tools lose any single step. The failure is never because something that should be done was ignored. Instead, the failure is often because of some non-fatal error that you have no hope of finding because it's mixed with 10k like of "build tool got here" spam.
- gregmac 5y ago
  Actually I totally agree with that. I was being generous in my example, and often what I showed as "Warning" is just a informational-level message. This leads to much more insidious problems like: ....(thousand of lines)... Info: Package X version 1.2.3 successfully added ....(thousand of lines)... Compile error: Unknown type Z Actual problem: Z was added in Package X version 1.3.0, but some other dependency or reference that wasn't updated caused the incorrect version to be loaded.
  - marcosdumay 5y ago
    If your code has any size, you won't get all that information from a builder log. Even if it is there, if you knew where to look you would have set the version limits correctly from the beginning. Fixing this on your own computer is quite straight forward, you just need to check the dependencies, you don't need the info line. Fixing that kind of problem on the build server is one of the reasons we have all those practices about reproducible compilation. On this specific case, it's a matter of freezing your dependencies.

marcosdumay 5y ago

The problem isn't the warnings and non-fatal errors. In fact, the largest problem is that the noise obscures them. The problem is the pages and pages of "did that, everything is fine". Since Linux distros stopped optimizing disk usage by omiting the update time of files a couple of decades ago, I haven't seen build tools lose any single step. The failure is never because something that should be done was ignored. Instead, the failure is often because of some non-fatal error that you have no hope of finding because it's mixed with 10k like of "build tool got here" spam.

gregmac 5y ago
Actually I totally agree with that. I was being generous in my example, and often what I showed as "Warning" is just a informational-level message. This leads to much more insidious problems like: ....(thousand of lines)... Info: Package X version 1.2.3 successfully added ....(thousand of lines)... Compile error: Unknown type Z Actual problem: Z was added in Package X version 1.3.0, but some other dependency or reference that wasn't updated caused the incorrect version to be loaded.
- marcosdumay 5y ago
  If your code has any size, you won't get all that information from a builder log. Even if it is there, if you knew where to look you would have set the version limits correctly from the beginning. Fixing this on your own computer is quite straight forward, you just need to check the dependencies, you don't need the info line. Fixing that kind of problem on the build server is one of the reasons we have all those practices about reproducible compilation. On this specific case, it's a matter of freezing your dependencies.