Add flag to replay to display output of failed builds #64

old commented 2025年08月04日 00:58:37 +02:00

Let's say someone invoke blue build and has an error when compiling some C file.

Basically, this would look like so:

CC libpatch/build/src/lib/libpatch/x86_64/patch.o
libpatch/src/lib/libpatch/x86_64/patch.c: In function 'add_resolve_pc_with_memory':
libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: error: 'a' undeclared (first use in this function)
 1364 | a;
 | ^
libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: note: each undeclared identifier is reported only once for each function it appears in
Build failed with 1 error:
 ERROR:
 1. &build-error
 2. &message: "Program invokation failed"
 3. &origin: "CC\tlibpatch/build/src/lib/libpatch/x86_64/patch.o"
 4. &irritants: "gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c"
make: *** [Makefile:4: all] Error 1

What I think would be nice is to have a builtin command that can list me the last errors again. For example, I might have closed the terminal or maybe I don't want to scroll back if I have lots of compiled fiels. I could just do:

blue last-error

and it will list all errors from the last build as a recutils list of records:

origin: libpatch/build/src/lib/libpatch/x86_64/patch.o
date: Sun 03 Aug 2025 08:39:09 PM EDT
details: 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288
command: gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c

Note that the origin field could actually be the source-location of the <c-binary> object, something like blueprint/builds.scm:40.

Then, we could use the details field to print the detailed error:

blue last-error 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288

would yield:

libpatch/src/lib/libpatch/x86_64/patch.c: In function 'add_resolve_pc_with_memory':
libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: error: 'a' undeclared (first use in this function)
 1364 | a;
 | ^
libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: note: each undeclared identifier is reported only once for each function it appears in

Thoughts?

Let's say someone invoke `blue build` and has an error when compiling some C file. Basically, this would look like so: ``` CC libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c: In function 'add_resolve_pc_with_memory': libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: error: 'a' undeclared (first use in this function) 1364 | a; | ^ libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: note: each undeclared identifier is reported only once for each function it appears in Build failed with 1 error: ERROR: 1. &build-error 2. &message: "Program invokation failed" 3. &origin: "CC\tlibpatch/build/src/lib/libpatch/x86_64/patch.o" 4. &irritants: "gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c" make: *** [Makefile:4: all] Error 1 ``` What I think would be nice is to have a builtin command that can list me the last errors again. For example, I might have closed the terminal or maybe I don't want to scroll back if I have lots of compiled fiels. I could just do: ```sh blue last-error ``` and it will list all errors from the last build as a recutils list of records: ``` origin: libpatch/build/src/lib/libpatch/x86_64/patch.o date: Sun 03 Aug 2025 08:39:09 PM EDT details: 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288 command: gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c ``` Note that the `origin` field could actually be the source-location of the `<c-binary>` object, something like `blueprint/builds.scm:40`. Then, we could use the `details` field to print the detailed error: ```sh blue last-error 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288 ``` would yield: ``` libpatch/src/lib/libpatch/x86_64/patch.c: In function 'add_resolve_pc_with_memory': libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: error: 'a' undeclared (first use in this function) 1364 | a; | ^ libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: note: each undeclared identifier is reported only once for each function it appears in ``` Thoughts?

pastor commented 2025年08月04日 09:07:54 +02:00

I love this idea! I'm guilty of pressing C-l too eagerly :').

@old wrote in #64 (comment):

What I think would be nice is to have a builtin command that can list me the last errors again. For example, I might have closed the terminal or maybe I don't want to scroll back if I have lots of compiled fiels. I could just do:

blue last-error

and it will list all errors from the last build as a recutils list of records:

origin: libpatch/build/src/lib/libpatch/x86_64/patch.o
date: Sun 03 Aug 2025 08:39:09 PM EDT
details: 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288
command: gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c

Note that the origin field could actually be the source-location of the <c-binary> object, something like blueprint/builds.scm:40.

I think this is more useful. Since as a user of the build system you want to know what triggered this erroneous build, would be nice to be able to retry the failed build. Regarding the information that should be shown, I think origin could show both, the source location of the build system and the target that triggered the command.

origin: blueprint/builds.scm:40: libpatch/build/src/lib/libpatch/x86_64/patch.o
date: Sun 03 Aug 2025 08:39:09 PM EDT
details: 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288
command: gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c

Then, we could use the details field to print the detailed error:

blue last-error 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288

would yield:

libpatch/src/lib/libpatch/x86_64/patch.c: In function 'add_resolve_pc_with_memory':
libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: error: 'a' undeclared (first use in this function)
 1364 | a;
 | ^
libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: note: each undeclared identifier is reported only once for each function it appears in

This is very nice. From what would be the hash to select the detailed view be computed, the contents plus the origin?

Thoughts?

10/10 must have.

I love this idea! I'm guilty of pressing C-l too eagerly :'). @old wrote in https://codeberg.org/lapislazuli/blue/issues/64#issue-2000080: > What I think would be nice is to have a builtin command that can list me the last errors again. For example, I might have closed the terminal or maybe I don't want to scroll back if I have lots of compiled fiels. I could just do: > > ```sh > blue last-error > ``` > > and it will list all errors from the last build as a recutils list of records: > > ```text > origin: libpatch/build/src/lib/libpatch/x86_64/patch.o > date: Sun 03 Aug 2025 08:39:09 PM EDT > details: 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288 > command: gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c > ``` > > Note that the `origin` field could actually be the source-location of the `<c-binary>` object, something like `blueprint/builds.scm:40`. I think this is more useful. Since as a user of the build system you want to know what triggered this erroneous build, would be nice to be able to retry the failed build. Regarding the information that should be shown, I think origin could show both, the source location of the build system and the target that triggered the command. ```text origin: blueprint/builds.scm:40: libpatch/build/src/lib/libpatch/x86_64/patch.o date: Sun 03 Aug 2025 08:39:09 PM EDT details: 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288 command: gcc -MMD -Ilibpatch/build -Ilibpatch/include -include libpatch/include/private/def.h -I/gnu/store/0wqw373ig0x7bi5jhdj0v4m15xsdfdz8-capstone-5.0.1/include/capstone -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/r9wba3ikmk4rx6mf6d6b0lfk3gdp6202-xz-5.4.5/include -I/gnu/store/s49v293nfyji7kik2z41zfrychja2qlj-elfutils-0.192/include -I/gnu/store/zi0sk0ir42360dnhfhmjp9pcg3gyi919-zlib-1.3.1/include -I/gnu/store/b64qwlab2191lab9kjh9j72q12y1b28j-libolx-1.7.0/include -I/gnu/store/4n3bd7xfdpc86r44h6hcywvqi91rlqx9-liburcu-0.14.1/include -Ilibpatch/src/lib/libpatch -Ilibpatch/src/lib/libpatch-common -Ilibpatch/src/lib/libpatch/x86_64/include -DLIBPATCH_CORE -fdiagnostics-color=always -O2 -g -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -O0 -ggdb3 -fvisibility=hidden -fPIC -c -o libpatch/build/src/lib/libpatch/x86_64/patch.o libpatch/src/lib/libpatch/x86_64/patch.c ``` > > Then, we could use the `details` field to print the detailed error: > > ```sh > blue last-error 750ed32e051ada8a85844b4ad82c7cbb159ca3497ada5d6db9114e602b8a2288 > ``` > > would yield: > > ```text > libpatch/src/lib/libpatch/x86_64/patch.c: In function 'add_resolve_pc_with_memory': > libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: error: 'a' undeclared (first use in this function) > 1364 | a; > | ^ > libpatch/src/lib/libpatch/x86_64/patch.c:1364:17: note: each undeclared identifier is reported only once for each function it appears in > ``` This is very nice. From what would be the hash to select the detailed view be computed, the contents plus the origin? > Thoughts? 10/10 must have.

old commented 2025年08月04日 18:30:23 +02:00

This is very nice. From what would be the hash to select the detailed view be computed, the contents plus the origin?

Inputs + output. So I would hash the command (gcc) and the output (error message)

10/10 must have.

Cool! I'm adding this to beta release. I'm just not sure about the naming of the command here. I'm open to suggestion for something else than last-error.

> This is very nice. From what would be the hash to select the detailed view be computed, the contents plus the origin? Inputs + output. So I would hash the command (gcc) and the output (error message) > 10/10 must have. Cool! I'm adding this to beta release. I'm just not sure about the naming of the command here. I'm open to suggestion for something else than `last-error`.

pastor commented 2025年08月05日 10:38:05 +02:00

Shouldn't we also include the origin field in the hashing? Specially if we will report the blue source location that trigger the build:

origin: blueprint/builds.scm:40: libpatch/build/src/lib/libpatch/x86_64/patch.o

It could be that the build system tries to build an artifact twice, right? So, although the error could be the same, it would be nice to print details of the iteration that raised it when doing blue last-error <hash>, instead of only having 1 error recorded when 2 happened.

Regarding the naming, since we could have multiple errors reported by this feature, what about something more descriptive?

For example:

$ blue error-log

Shouldn't we also include the `origin` field in the hashing? Specially if we will report the blue source location that trigger the build: ``` origin: blueprint/builds.scm:40: libpatch/build/src/lib/libpatch/x86_64/patch.o ``` It could be that the build system tries to build an artifact twice, right? So, although the error could be the same, it would be nice to print details of the iteration that raised it when doing `blue last-error <hash>`, instead of only having 1 error recorded when 2 happened. Regarding the naming, since we could have multiple errors reported by this feature, what about something more descriptive? For example: ``` $ blue error-log ```

pastor commented 2025年08月05日 10:40:57 +02:00

Now that I think of it. I think some of built-in commands are imperative: configure, help, etc...

Maybe it would be more consistent to have something like:

$ blue log-errors

Although I'm not sure if this is clear... To me it sounds like we are instructing the build system to log the errors for the next execution... What do you think?

Now that I think of it. I think some of built-in commands are imperative: `configure`, `help`, etc... Maybe it would be more consistent to have something like: ``` $ blue log-errors ``` Although I'm not sure if this is clear... To me it sounds like we are instructing the build system to log the errors for the next execution... What do you think?

old commented 2025年08月05日 15:40:54 +02:00

How about replay?

$ blue replay [--rerun] [HASH]

$ blue replay # List the last build errors

$ blue replay --rerun # Rerun the previous failed build

$ blue replay HASH # Display the error of item HASH of last failed build

$ blue replay --rerun HASH # Rerun the item HASH of last failed build

Maybe that is too much. Also I'm not sure if replay would be the wording to choose here.

How about `replay`? `$ blue replay [--rerun] [HASH]` `$ blue replay # List the last build errors` `$ blue replay --rerun # Rerun the previous failed build` `$ blue replay HASH # Display the error of item HASH of last failed build` `$ blue replay --rerun HASH # Rerun the item HASH of last failed build` Maybe that is too much. Also I'm not sure if `replay` would be the wording to choose here.

pastor commented 2025年08月06日 22:12:48 +02:00

I actually think that replay it's very consistent with the interface you describe. I like it, let's go with it!

I actually think that `replay` it's very consistent with the interface you describe. I like it, let's go with it!

old commented 2025年08月15日 20:06:25 +02:00

Done in ee4f5d876e

Done in ee4f5d876eb1be37c325886cac50e0908da48fa5

pastor commented 2025年08月16日 16:51:58 +02:00

I think we should add some unit tests for the replay command, probably under tests/regression/bugs/ui.scm.

I think we should add some unit tests for the `replay` command, probably under `tests/regression/bugs/ui.scm`.

old commented 2025年08月17日 03:41:54 +02:00

Under tests/regression/features/replay.scm or tests/regression/commands/replay.scm.bugs is only for opened issues.

Under `tests/regression/features/replay.scm` or `tests/regression/commands/replay.scm`.`bugs` is only for opened issues.

old commented 2025年08月20日 19:27:47 +02:00

Opening again since we want to change the interface:

# blue replay [COMMANDS | HASHES] ...
Replay the last failed command or COMMANDS and HASHES.
Auto-complete to last failed command names or hashes.
# blue replay --details [COMMANDS] ...
List the details of the last failed command or COMMANDS as recutils records.
Auto-complete to last failed command names.
# blue replay --all-details
List the details of all the last failed commands. To be used by external tools.

Opening again since we want to change the interface: ``` # blue replay [COMMANDS | HASHES] ... Replay the last failed command or COMMANDS and HASHES. Auto-complete to last failed command names or hashes. # blue replay --details [COMMANDS] ... List the details of the last failed command or COMMANDS as recutils records. Auto-complete to last failed command names. # blue replay --all-details List the details of all the last failed commands. To be used by external tools. ```