From a9c914fedda5e1240e5b59e66c3c906ea673e854 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Vig=C3=A9e?= Date: Thu, 25 Jun 2026 09:52:35 +0100 Subject: [PATCH] docs(gha): update comment-reset and status-emoji descriptions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two behavioral corrections from hephbuild/heph#129: 1. The heading emoji is now driven by the invocation's stream lifecycle (closed = done), not by "every matched target finished." The old phrasing was wrong for transparent-group targets that never emit ResultEnd — the emoji is now ✅ when the command exits, not when done == total. 2. Each new workflow run (GITHUB_RUN_ID + GITHUB_RUN_ATTEMPT) resets the comment's sections. The previous "reused across reruns, never duplicated" text didn't capture this: stale sections from a prior build are now cleared when the first step of a new run writes. --- website/docs/plugins/gha.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/website/docs/plugins/gha.md b/website/docs/plugins/gha.md index 35ac5cd..d927e48 100644 --- a/website/docs/plugins/gha.md +++ b/website/docs/plugins/gha.md @@ -126,8 +126,8 @@ While the build runs the comment shows live progress: ``` -The heading emoji reflects the current state: ⏳ while running, ✅ once every -matched target finishes without error, ❌ as soon as any target fails. +The heading emoji reflects the current state: ⏳ while the command is running, +✅ once the command finishes without error, ❌ if any target failed. A total shown as `~40` means the matcher hasn't resolved all targets yet; the tilde drops once resolution is complete. @@ -137,9 +137,14 @@ address and the first line of its error message. ## One comment per job, one section per step -The comment is scoped by `GITHUB_JOB` — one comment per CI job, reused across -reruns (found by a hidden HTML marker, never duplicated). Within the comment, -each heph invocation owns a section keyed by its command line (the arguments -passed to `heph`). A job with three separate `heph run` steps produces one -comment with three independently-updated sections, so earlier steps' results -are preserved as later steps write theirs. +The comment is scoped by `GITHUB_JOB` — one comment per CI job, never +duplicated (found by a hidden HTML marker). Within the comment, each heph +invocation owns a section keyed by its command line (the arguments passed to +`heph`). A job with three separate `heph run` steps produces one comment with +three independently-updated sections, so earlier steps' results are preserved +as later steps write theirs. + +Each new workflow run (identified by `GITHUB_RUN_ID` and `GITHUB_RUN_ATTEMPT`) +starts the comment fresh — the previous build's sections are cleared when the +first step of a new run writes to the comment. Steps within the same run +continue to preserve each other's sections as described above.