More CI woes

[Andrei Alexandrescu]

On 9/20/20 2:35 AM, Seb wrote:
> Well, your PRs break the world and this time the CIs actually manage to 
> catch it.
> Have a look at the Buildkite output of your PR: 
> https://buildkite.com/dlang/phobos/builds/3903 where it breaks the build 
> of many real-world projects:

Yes, that's great. Thanks. Some of the logs are easier to get into than 
others.

>> * It's 2942 lines long. Most of these lines are just chaff,
> 
> Well, extra verbosity is nice when things fail.
> Why don't you scroll to the bottom?

Extra verbosity is best when informative.

I understand and agree with this and all of your points. In fact I could 
have written a similar reply to my own post. It's all a matter of where 
we come from - if I came from the vantage point "Here's another baseless 
complaint about the logs that work just fine, let's deconstruct it" the 
reply would come one way. The problem being, of course, that that sets 
up the suggester and the maintainer on reciprocally defensive positions, 
whereby energy goes in the back-and-forth instead of productive 
improvements.

If we look at things as "logs are good and could be better, let's see 
how we can get information from here to improve the lot of contributors" 
then the answer comes very differently. From the same person!

> Huh, it yields a fairly nice nice error message: (it's from the link you 
> posted)
> 
> ---
> The following operation failed:
> Dependencies:
>   -> dmd
>   -> /dev/shm/dtest/work/repo/dmd/generated/linux/release/64/VERSION
>   -> /dev/shm/dtest/work/repo/dmd/generated/linux/release/64/SYSCONFDIR.imp
> 
> Sources:
>   -> /dev/shm/dtest/work/repo/dmd/src/dmd/frontend.d
> 
> Targets:
>   -> 
> /dev/shm/dtest/work/repo/dlang.org/web/phobos-prerelease/dmd_frontend.html
> 
> Command: /dev/shm/dtest/work/repo/dmd/generated/linux/release/64/dmd -o- 
> -c -Dd/dev/shm/dtest/work/repo/dlang.org 
> -J/dev/shm/dtest/work/repo/dmd/src/dmd/res 
> -I/dev/shm/dtest/work/repo/dmd/src/dmd 
> /dev/shm/dtest/work/repo/dmd/src/project.ddoc 
> -Df/dev/shm/dtest/work/repo/dlang.org/web/phobos-prerelease/dmd_frontend.html 
> src/dmd/frontend.d -version=MARS -w -de -fPIC -m64 
> -J/dev/shm/dtest/work/repo/dmd/generated/linux/release/64 
> -I/dev/shm/dtest/work/repo/dmd/src -dip25 -g -color=on
> ---

A couple of things come to mind.

* The line where the build failed in frontend.d would be good to have.

* The word "error" does not appear anywhere. "Failed" is good, but it 
would be great to distinguish these particular lines as the cause of 
failure. This is because there are several other places that one may 
legitimately think are problematic, such as:

magic.d(9:39)[error]: Declaration expected
magic.d(76:1)[error]: Declaration expected
magic.d(15:1)[error]: Declaration expected
... about a dozen like these ...

and:

No type found for dmd.parse.Parser.Parser.NeedDeclaratorId.
Error parsing type 'const(void function()* function() pure nothrow 
@property @nogc)': Missing ')' for 'const('
Function object.ModuleInfo.tlsctor has non-function type: Primitive
Error parsing type 'const(void function()* function() pure nothrow 
@property @nogc)': Missing ')' for 'const('
... about three dozen like these ...

I mean these don't look like something a build would come back from. In 
fact I legit thought there was some breakage in the CI system and wanted 
to ask about it. The clue that stopped me from doing this was there was 
a lot more output after that.

>> Command lines are definitely something people would want to copy and 
>> paste from the log. They should be printed like this:
> 
> I am sorry, but I don't see your point.
> 1) The command as run must be displayed (no modification)
> 2) They actually work as displayed. Try `'timeout' '2s' 'sleep' '5s'` in 
> your shell.

Of course. However, workable does not necessarily mean adequate. That's 
not how people read and write shell commands. I wouldn't want to edit 
such a command or have it in my .history file. We shouldn't make it 
unnecessarily difficult for people to read and edit such commands. Most 
commands appear in a different manner, this is not something one would 
want to go out of one's way to differentiate.

I was thinking, for example, we could add to std.process a function 
shellQuote that, given a string, returns that string with minimal 
additions of escapes to be run in a shell. In fact I think rdmd had such 
a function at a point, because it's still in one comment: 
https://github.com/dlang/tools/blob/master/rdmd.d#L698.

>> > They have escape sequences for pretty printing with colors.
>> Whatever system is producing that output should detect it's not 
>> running in a console and omit the escape sequences.
> 
> https://issues.dlang.org/show_bug.cgi?id=21266

That's the spirit. Thanks! Probably -color=off in the cmdline would suffice?