amtronics/platform-actions

Watch

Fork 0

chore: Migrate the remaining reporters onto report-job-failure #46

New issue

Open

opened 2026-09-05 07:06:04 +00:00 by ahmad · 1 comment

ahmad commented

2026-09-05 07:06:04 +00:00

Owner

Context

report-job-failure exists and is released — v3 now points at 71fb9d5a (v3.7.0) and carries the action. #38 migrated this repository's own validate onto it, which proved equivalence; the other three consumers still run hand-copied reporters:

ahmad/expiro      validate   and   image
ahmad/portfolio   validate
ahmad/imamah      checks               (posts via node fetch — see below)

Each copy is where the drift lives, and the drift is not hypothetical: two of the copies have already had the unreachable-fallback bug fixed separately (ahmad/expiro#27, and this repository's own in #38), which is three independent fixes for one defect.

Scope

In: each consumer's reporter step replaced by uses: …/report-job-failure@v3, its captured log path passed through, and the comment it produces unchanged.
Out: the capture half — each job keeps its own tee under pipefail, which an action cannot do for it.
Out: security-scan's internal capture, which exposes log-path and would become a consumer separately.

Acceptance criteria

Given each consumer above, when its reporter step is read, then it uses the shared action rather than an inline script.
Given a consumer's job fails, when the action runs, then the comment carries the same tail the inline version would have.
Given a consumer on an image without curl or jq, when the action runs, then either the image provides them or that consumer keeps its own reporter, decided explicitly rather than by accident.
Given the migrations are done, when the repositories are searched, then no inline failure-tail reporter remains.

Notes

One pull request per repository. Three repositories in one change could not be reviewed or reverted as a unit, and two of them currently cannot get a green pipeline at all — ahmad/expiro's image job has failed on the Docker Hub base-image pull seven times today, with two of its pull requests parked on exactly that. Expect expiro to be the slowest of the three and do not let it block the others.

ahmad/imamah is the one to think about rather than copy. Its checks job container is node:22-bookworm and its reporter posts through node's global fetch precisely because curl is not guaranteed there. Migrating it means either installing curl and jq in that job or leaving it on its own reporter — the third criterion exists so that is a decision someone makes, not one that emerges from a failed run. The action guards both dependencies and exits 0 with a message, so the failure mode is legible either way, but a consumer that silently never posts is worth avoiding.

### Context `report-job-failure` exists and is released — `v3` now points at `71fb9d5a` (v3.7.0) and carries the action. `#38` migrated this repository's own `validate` onto it, which proved equivalence; the other three consumers still run hand-copied reporters: ``` ahmad/expiro validate and image ahmad/portfolio validate ahmad/imamah checks (posts via node fetch — see below) ``` Each copy is where the drift lives, and the drift is not hypothetical: two of the copies have already had the unreachable-fallback bug fixed separately (`ahmad/expiro#27`, and this repository's own in #38), which is three independent fixes for one defect. ### Scope - In: each consumer's reporter step replaced by `uses: …/report-job-failure@v3`, its captured log path passed through, and the comment it produces unchanged. - Out: the *capture* half — each job keeps its own `tee` under `pipefail`, which an action cannot do for it. - Out: `security-scan`'s internal capture, which exposes `log-path` and would become a consumer separately. ### Acceptance criteria - [ ] Given each consumer above, when its reporter step is read, then it uses the shared action rather than an inline script. - [ ] Given a consumer's job fails, when the action runs, then the comment carries the same tail the inline version would have. - [ ] Given a consumer on an image without `curl` or `jq`, when the action runs, then either the image provides them or that consumer keeps its own reporter, decided explicitly rather than by accident. - [ ] Given the migrations are done, when the repositories are searched, then no inline failure-tail reporter remains. ### Notes **One pull request per repository.** Three repositories in one change could not be reviewed or reverted as a unit, and two of them currently cannot get a green pipeline at all — `ahmad/expiro`'s `image` job has failed on the Docker Hub base-image pull seven times today, with two of its pull requests parked on exactly that. Expect expiro to be the slowest of the three and do not let it block the others. **`ahmad/imamah` is the one to think about rather than copy.** Its `checks` job container is `node:22-bookworm` and its reporter posts through node's global `fetch` precisely because `curl` is not guaranteed there. Migrating it means either installing `curl` and `jq` in that job or leaving it on its own reporter — the third criterion exists so that is a decision someone makes, not one that emerges from a failed run. The action guards both dependencies and exits 0 with a message, so the failure mode is legible either way, but a consumer that silently never posts is worth avoiding.

ahmad added the

labels

2026-09-05 07:06:04 +00:00

ahmad self-assigned this

2026-09-06 00:33:45 +00:00

ahmad added

state/in-progress

and removed

state/ready

labels

2026-09-06 00:33:46 +00:00

ahmad referenced this issue

2026-09-06 00:39:56 +00:00

fix: report-job-failure cannot post from a node-only image, so it never posts at all #52

ahmad commented

2026-09-06 00:40:21 +00:00

Author

Owner

Taking this, and stopping before the first migration — because the premise does not hold as written.

report-job-failure cannot post from any of the three consumers' images. It builds its body with jq and exits 0 without posting when jq is missing. jq is absent from node:22-bookworm, which this repository already knows: release.yml says so in a comment and uses node instead, deliberately.

amtronics/platform-actions  validate  node:22-bookworm   uses ./report-job-failure   <-- #38
ahmad/portfolio             validate  node:22-bookworm   inline node
ahmad/imamah                checks    node:22-bookworm   inline node
ahmad/expiro                validate  node:22-bookworm   inline node
ahmad/expiro                image     (host runner)      inline node

Migrating the three as written would silently disable all of them. This repository's own validate has already been a silent no-op since #38 merged — it just has not failed since, so nothing revealed it.

Filed as #52, and it blocks this issue. I have not opened any migration PR.

Three corrections to this issue's inventory, all found by looking rather than by assuming:

ahmad/portfolio has two reporters, not one. validate step 10 and e2e step 6. The e2e one runs in mcr.microsoft.com/playwright:v1.61.1-noble, a different image again, and needs its own answer to the third criterion.
The node-fetch reporter is not unique to ahmad/imamah. Every inline reporter on the fleet — portfolio's two, expiro's two, imamah's one — posts through node -e, for the same reason. The issue frames imamah as the exception to think about; it is the rule.
ahmad/expiro is not the slowest consumer, it is the only one that has ever posted. Twenty failure comments, nineteen from image and one from validate. portfolio, imamah and this repository have posted zero — not because they are broken, but because their jobs have not failed on a pull request. That is worth knowing before treating "it works in expiro" as evidence the pattern works.

A near-miss worth recording, since it nearly became a false report: my first search for posted comments found zero everywhere, and I was about to report that the reporter had never worked at all. The search string was wrong — I had built it from the current action.yml wording rather than from a comment anyone had actually posted, and the real ones say "so it can be read without the run log". Constructing a search from the source rather than from observed output is how you confirm a thing that is not true.

Suggested sequencing once #52 lands: ahmad/portfolio first (two reporters, one of them on a third image, so it settles the e2e question early), then ahmad/imamah, then ahmad/expiro last — its pull requests are already blocked on a red image check for unrelated runner reasons.

Taking this, and stopping before the first migration — because the premise does not hold as written. **`report-job-failure` cannot post from any of the three consumers' images.** It builds its body with `jq` and exits 0 without posting when `jq` is missing. `jq` is absent from `node:22-bookworm`, which this repository already knows: `release.yml` says so in a comment and uses `node` instead, deliberately. ``` amtronics/platform-actions validate node:22-bookworm uses ./report-job-failure <-- #38 ahmad/portfolio validate node:22-bookworm inline node ahmad/imamah checks node:22-bookworm inline node ahmad/expiro validate node:22-bookworm inline node ahmad/expiro image (host runner) inline node ``` Migrating the three as written would silently disable all of them. **This repository's own `validate` has already been a silent no-op since #38 merged** — it just has not failed since, so nothing revealed it. Filed as #52, and it blocks this issue. I have not opened any migration PR. **Three corrections to this issue's inventory, all found by looking rather than by assuming:** 1. **`ahmad/portfolio` has two reporters, not one.** `validate` step 10 and `e2e` step 6. The `e2e` one runs in `mcr.microsoft.com/playwright:v1.61.1-noble`, a different image again, and needs its own answer to the third criterion. 2. **The node-fetch reporter is not unique to `ahmad/imamah`.** Every inline reporter on the fleet — portfolio's two, expiro's two, imamah's one — posts through `node -e`, for the same reason. The issue frames imamah as the exception to think about; it is the rule. 3. **`ahmad/expiro` is not the slowest consumer, it is the only one that has ever posted.** Twenty failure comments, nineteen from `image` and one from `validate`. `portfolio`, `imamah` and this repository have posted **zero** — not because they are broken, but because their jobs have not failed on a pull request. That is worth knowing before treating "it works in expiro" as evidence the pattern works. **A near-miss worth recording**, since it nearly became a false report: my first search for posted comments found zero everywhere, and I was about to report that the reporter had never worked at all. The search string was wrong — I had built it from the current `action.yml` wording rather than from a comment anyone had actually posted, and the real ones say "so it can be read *without* the run log". Constructing a search from the source rather than from observed output is how you confirm a thing that is not true. **Suggested sequencing once #52 lands:** `ahmad/portfolio` first (two reporters, one of them on a third image, so it settles the `e2e` question early), then `ahmad/imamah`, then `ahmad/expiro` last — its pull requests are already blocked on a red `image` check for unrelated runner reasons.

ahmad added

state/ready

and removed

state/in-progress

labels

2026-09-06 00:40:23 +00:00

ahmad removed their assignment

2026-09-06 00:40:24 +00:00

ahmad referenced this issue

2026-09-06 00:42:58 +00:00

fix: Build the comment body without requiring jq #53

ahmad self-assigned this