fix(reports): GitHub Actions annotations never reached the pull request by Chemaclass · Pull Request #1042 · TypedDevs/bashunit

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass · 2026-08-10T14:07:26Z

🤔 Background

Related #1014

bashunit could produce GitHub Actions annotations, but they never reached a pull request. GitHub parses workflow commands from the job log, and the only caller wrote them to a file instead of stdout. The flag was undocumented, and the official action never wired it, so users of TypedDevs/bashunit@v0 got nothing.

💡 Changes

Annotations now print to stdout automatically inside GitHub Actions, with the failing test's file and line so they land on the right line of the diff. No flag needed.
--gha-annotations <auto|always|never> overrides the detection; auto also stays quiet under --output tap.
--log-gha keeps writing its file, is now listed in --help, and the two sinks never duplicate each other in the job log.
action.yml gains an annotations input, and row collection is enabled when annotations will print, which also keeps them working under --parallel.

GitHub parses workflow commands from the job log, and bashunit only ever wrote them to a file. print_gha_annotations already emitted correct `::error file=...,line=...` lines, but the sole caller redirected them into $BASHUNIT_LOG_GHA, so a file nobody cat'd produced zero annotations. The flag was also missing from `bashunit test --help`, and the official action never wired any of it, so users of TypedDevs/bashunit@v0 got nothing at all. Annotations now go to stdout, automatically, whenever GITHUB_ACTIONS is true. --gha-annotations auto|always|never overrides the detection. `auto` also stays quiet under --output tap, whose stdout is a machine format an annotation line would corrupt. reports::is_enabled had to learn about this too: it gates row collection, so without it the arrays stayed empty and there was nothing to annotate when no other report flag was set. Printing happens after load_spooled so a --parallel run annotates the rows its workers spooled, which the parent would otherwise never have seen (#1004). --log-gha keeps writing the file and is now documented. The two sinks are independent, so using both does not duplicate anything in the job log. Closes#1014

GITHUB_ACTIONS is inherited by every child process, so auto-detection alone made every nested bashunit run annotate its parent's job log with its own fixtures' failures. bashunit's own acceptance suite spawns ~258 nested runs, which is how CI caught it; a user's script under test that calls bashunit would have polluted their log the same way. A run claims the log by exporting a marker and reading it first, so the outermost process wins and every descendant stays quiet. The marker is deliberately exported, unlike the run-mode flags: the nested run is exactly the consumer that has to see it. The reports unit tests ask whether a *file* report was configured. Annotations are a second reason to collect rows and switch themselves on inside GitHub Actions, so they are pinned off there to keep the answer independent of the ambient environment.

Chemaclass added the bug Something isn't working label Aug 10, 2026

Chemaclass self-assigned this Aug 10, 2026

Chemaclass merged commit 54f9e97 into mainAug 10, 2026
40 checks passed

Chemaclass deleted the fix/1014-gha-annotations branch August 10, 2026 14:32