Skip to content

fix(reports): GitHub Actions annotations never reached the pull request - #1042

Merged
Chemaclass merged 2 commits into
mainfrom
fix/1014-gha-annotations
Aug 10, 2026
Merged

fix(reports): GitHub Actions annotations never reached the pull request#1042
Chemaclass merged 2 commits into
mainfrom
fix/1014-gha-annotations

Conversation

@Chemaclass

Copy link
Copy Markdown
Member

🤔 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
@Chemaclass Chemaclass added the bug Something isn't working label Aug 10, 2026
@Chemaclass Chemaclass self-assigned this Aug 10, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant