3 ms·
Literally every single sibling comment is missing the point. Yes, this data should be recorded. Yes, it should be viewable. Should it be viewed as a continuo
by formerly_proven 5y ago
Literally every single sibling comment is missing the point.
Yes, this data should be recorded.
Yes, it should be viewable.
Should it be viewed as a continuous 34000 line log file?
Of course not. But this is what many (most?) CI tools do. The correct way is to group output at least by step, make log output from various parts of the system collapsible etc., for example, dumping all environment variables and component versions at every step CAN be helpful to diagnose issue, but usually isn't. So it should be collapsed by default.
Edit: I have the exact same gripe with all of the log4j inspired logging libraries, which in my opinion provide very little value over a print. To little structure, no way to hold back output until you have an error, temporary redirects are difficult and have to modify global state and so on. Uninspired design providing minimal utility.
- amelius 5y agoInstead of collapsing, you can grep through them.
- exdsq 5y agoAssuming you know the word you're looking for, at least collapsible errors are easier to explore
- lumost 5y agoBut then I can’t grep/search.
- cortesoft 5y ago“Collapsible” implies using some sort of interface for looking at the logs… that interface can also include grep/search functionality that searches all the lines. It could also include functionality to let you download the entire raw log to grep locally.
- Nextgrid 5y ago> The correct way is to group output at least by step, make log output from various parts of the system collapsible etc., for example, dumping all environment variables and component versions at every step CAN be helpful to diagnose issue, but usually isn't. So it should be collapsed by default. Which means test tools should conform to some agreed-upon universal output format for their console (and make sure none of the underlying libraries print anything to stdout) or have an out-of-band way to communicate with the CI system in real-time (XUnit/Junit isn’t good enough as those are only typically written at the end of the process).
- formerly_proven 5y agoMost CI tools support some notion of multiple stages and tasks; it would already be helpful if they were able to separate the output of those instead of barfing it all into one log file. IIRC, Travis has been doing this since at least 2016 where they collapse most of the setup steps by default - and if you are interested, it only takes one click. This of course only applies to the UI, the raw log is complete.
- goguy 5y agoThis is the case with the gitlab ci runner too. Only logs related to the specific job are present in the UI.
- maccard 5y agoOut of curiosity what tools _dont_ do this by default? I've been using TeamCity for a decade and it has supported that feature. I used (shudder) electric commander before that and it also supported it.
- formerly_proven 5y agoThe company which makes Jira also makes a CI server.