chore: align commit-message workflow #9

Merged
jercik merged 1 commit from chore/align-runtime-15-2-5 into main 2026-10-25 10:03:21 +00:00
Owner

Synchronizes the commit-message workflow with released Align 15.2.5.

Synchronizes the commit-message workflow with released Align 15.2.5.
chore: align commit-message workflow
All checks were successful
Checks / pr-flow-canary (pull_request) Has been skipped
commit-msg / commitlint (pull_request) Successful in 4s
Checks / reuse (pull_request) Successful in 6s
Checks / quality-checks (24.15.0) (pull_request) Successful in 33s
Checks / quality-checks (26.12.1) (pull_request) Successful in 42s
Review / Review (pull_request_target) Successful in 5m34s
0250aef80f

Review 01M5S78SF46R2H7PVPJS54RGVF — head 0250aef80fd573e96d189e8f0fee4ce5a6ec0b1f

Review — j4k-oss/conventional-commit-msg @ 7fe6dca5dd

Scope: diff against base tree 6621da7a1b9f
Review finished: 5 succeeded, 0 failed, 5 skipped by dispatch
Triage: settled
Facts: current review-wide projection

Computed under:

{
  "abandonment": "abandonment-v1",
  "anchor_recipe": 1,
  "batch_policy": "batch-v1",
  "coverage": "coverage-v3",
  "dispatch_policy": "dispatch-v2",
  "grounder_version": 1,
  "grounding_read_rule": "grounding-read-v1",
  "promotion_policy": "promotion-v1",
  "report": "report-v5",
  "tally": "tally-v1",
  "triage_settle": "triage-settle-v2"
}

Findings (1)

low — commit-msg job still runs node -e but no longer provisions Node, so the PR metadata parser silently depends on the runner image's ambient runtime

  • claim: 01M5S7DY0Y8NAC3GY5XTWN12RG
  • anchor: .forgejo/workflows/commit-msg.yml (snippet)
printf '%s' "$pr_json" | FIELD_REF="$pr_fields/ref" FIELD_TITLE="$pr_fields/title" node -e
  • lens: aposd-plain · arm: default
  • verdicts: 1 valid / 0 invalid / 0 uncertain
    • pass 01M5S7EAZ70KZ5P8569EPE32S6 · valid: Grounded (exact) snippet confirms the commitlint job still pipes the PR JSON into 'node -e' to write the ref/title files the validation step reads. The reviewer reports, specifically and consistently, that the diff deletes the only Node provisioning in the job (actions/setup-node@v6, node-version 26.12.1, commented 'Policy-pinned runtime for the refreshed PR metadata parser'). Nothing in the batch contradicts that. After the deletion, which Node runs the parser depends on whatever the runner image ships, and the workflow never says so. That is the obscurity behind APoSD's Nonobvious Code red flag: a hidden dependency, which also drops a pin the removed comment called policy. JavaScript actions probably keep some Node present, so nothing is broken today, and the reviewer's low severity fits. The claim already covers the chance that the PR meant to rely on runner Node: that would still leave an undocumented dependency. No substantive objection survives. Remedy: restore setup-node with node-version-file: .node-version, matching dedupe-check.yml and release.yml as reported, or parse the two fields without Node.
  • disposition: none

After this change, nothing in the commitlint job says which Node runs the PR metadata parser. The job's correctness now rests on a fact about the ubuntu-latest runner image that appears nowhere in the workflow. If the image drops Node or ships a different major, the "Read the current pull request" step fails or changes behavior. The check then fails closed and blocks every same-repo PR, and nothing in this file points to the cause. In APOSD terms this is nonobvious code: the step has a hidden dependency.

The diff deletes the Setup Node.js step (actions/setup-node@v6 with node-version: "26.12.1" and the comment "Policy-pinned runtime for the refreshed PR metadata parser"). The next step still pipes the API response into node -e '...JSON.parse(s)...pr?.base?.ref...' to write the ref and title files that the validation step reads.

The removed step did have a flaw: it hard-coded 26.12.1, a second copy of .node-version. The fix for that copy is to read the authority file, not to drop the provisioning. dedupe-check.yml and release.yml both use actions/setup-node@v6 with node-version-file: ".node-version". Restoring the step in that form brings back the explicit runtime and leaves .node-version as the only place the version is set. The other fix is to stop needing Node in this job, by parsing the two fields with a tool the step already relies on.

What I examined: the full diff (only this file changed, six lines deleted), commit-msg.yml in the subject tree, .node-version (26.12.1), package.json engines.node (>=24.15.0), and the setup-node usage in checks.yml, dedupe-check.yml and release.yml. I could not check what Node the Forgejo ubuntu-latest image provides. JavaScript actions like actions/checkout@v6 probably need some node in the job container, so the step probably works today on an unpinned version. That is why the severity is low: the cost is the hidden, unpinned dependency, not a breakage I observed. The PR description, which I cannot see, might state an intent to rely on the runner's Node. That would change the claim from a defect to an undocumented choice that needs a one-line comment.

Other claims

  • grounding-pending (0)
  • ungrounded (0)
  • rejected (0)
  • duplicate-of (0)
  • unadjudicated (0)

Coverage

Coverage pass: 01M5S795CZK9ECQTJ320D75WPC
Accounting: complete (all slots terminal; see slot results for failures)
Slot health: healthy

lens part arm unit status runs loss
restated-sets whole default no-claims 1 no
module-design whole default no-claims 1 no
aposd-plain whole default claims-emitted 1 no
general-bug whole default no-claims 1 no
project-docs whole default no-claims 1 no
  • writing-quality — skipped-by-dispatch: no prose or user-facing text changed; only a workflow step removed
  • test-trimming — skipped-by-dispatch: no tests changed
  • unix-cli — skipped-by-dispatch: no CLI code or interface changed
  • use-effect — skipped-by-dispatch: CI workflow YAML only; no React code
  • react — skipped-by-dispatch: CI workflow YAML only; no React code
<!-- review:summary --> **Review** `01M5S78SF46R2H7PVPJS54RGVF` — head `0250aef80fd573e96d189e8f0fee4ce5a6ec0b1f` # Review — j4k-oss/conventional-commit-msg @ 7fe6dca5dde5 Scope: diff against base tree `6621da7a1b9f` Review finished: 5 succeeded, 0 failed, 5 skipped by dispatch Triage: settled Facts: current review-wide projection Computed under: ```json { "abandonment": "abandonment-v1", "anchor_recipe": 1, "batch_policy": "batch-v1", "coverage": "coverage-v3", "dispatch_policy": "dispatch-v2", "grounder_version": 1, "grounding_read_rule": "grounding-read-v1", "promotion_policy": "promotion-v1", "report": "report-v5", "tally": "tally-v1", "triage_settle": "triage-settle-v2" } ``` ## Findings (1) ### low — commit-msg job still runs `node -e` but no longer provisions Node, so the PR metadata parser silently depends on the runner image's ambient runtime - claim: `01M5S7DY0Y8NAC3GY5XTWN12RG` - anchor: `.forgejo/workflows/commit-msg.yml` (snippet) ``` printf '%s' "$pr_json" | FIELD_REF="$pr_fields/ref" FIELD_TITLE="$pr_fields/title" node -e ``` - lens: aposd-plain · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5S7EAZ70KZ5P8569EPE32S6` · valid: Grounded (exact) snippet confirms the commitlint job still pipes the PR JSON into 'node -e' to write the ref/title files the validation step reads. The reviewer reports, specifically and consistently, that the diff deletes the only Node provisioning in the job (actions/setup-node@v6, node-version 26.12.1, commented 'Policy-pinned runtime for the refreshed PR metadata parser'). Nothing in the batch contradicts that. After the deletion, which Node runs the parser depends on whatever the runner image ships, and the workflow never says so. That is the obscurity behind APoSD's Nonobvious Code red flag: a hidden dependency, which also drops a pin the removed comment called policy. JavaScript actions probably keep some Node present, so nothing is broken today, and the reviewer's low severity fits. The claim already covers the chance that the PR meant to rely on runner Node: that would still leave an undocumented dependency. No substantive objection survives. Remedy: restore setup-node with node-version-file: .node-version, matching dedupe-check.yml and release.yml as reported, or parse the two fields without Node. - disposition: none > After this change, nothing in the `commitlint` job says which Node runs the PR metadata parser. The job's correctness now rests on a fact about the `ubuntu-latest` runner image that appears nowhere in the workflow. If the image drops Node or ships a different major, the "Read the current pull request" step fails or changes behavior. The check then fails closed and blocks every same-repo PR, and nothing in this file points to the cause. In APOSD terms this is nonobvious code: the step has a hidden dependency. > > The diff deletes the `Setup Node.js` step (`actions/setup-node@v6` with `node-version: "26.12.1"` and the comment "Policy-pinned runtime for the refreshed PR metadata parser"). The next step still pipes the API response into `node -e '...JSON.parse(s)...pr?.base?.ref...'` to write the `ref` and `title` files that the validation step reads. > > The removed step did have a flaw: it hard-coded `26.12.1`, a second copy of `.node-version`. The fix for that copy is to read the authority file, not to drop the provisioning. `dedupe-check.yml` and `release.yml` both use `actions/setup-node@v6` with `node-version-file: ".node-version"`. Restoring the step in that form brings back the explicit runtime and leaves `.node-version` as the only place the version is set. The other fix is to stop needing Node in this job, by parsing the two fields with a tool the step already relies on. > > What I examined: the full diff (only this file changed, six lines deleted), `commit-msg.yml` in the subject tree, `.node-version` (`26.12.1`), `package.json` `engines.node` (`>=24.15.0`), and the setup-node usage in `checks.yml`, `dedupe-check.yml` and `release.yml`. I could not check what Node the Forgejo `ubuntu-latest` image provides. JavaScript actions like `actions/checkout@v6` probably need some `node` in the job container, so the step probably works today on an unpinned version. That is why the severity is low: the cost is the hidden, unpinned dependency, not a breakage I observed. The PR description, which I cannot see, might state an intent to rely on the runner's Node. That would change the claim from a defect to an undocumented choice that needs a one-line comment. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (0) ## Coverage Coverage pass: 01M5S795CZK9ECQTJ320D75WPC Accounting: complete (all slots terminal; see slot results for failures) Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | restated-sets | whole | default | no-claims | 1 | no | | module-design | whole | default | no-claims | 1 | no | | aposd-plain | whole | default | claims-emitted | 1 | no | | general-bug | whole | default | no-claims | 1 | no | | project-docs | whole | default | no-claims | 1 | no | - writing-quality — skipped-by-dispatch: no prose or user-facing text changed; only a workflow step removed - test-trimming — skipped-by-dispatch: no tests changed - unix-cli — skipped-by-dispatch: no CLI code or interface changed - use-effect — skipped-by-dispatch: CI workflow YAML only; no React code - react — skipped-by-dispatch: CI workflow YAML only; no React code
Author
Owner

Review outcome for claim 01M5S7DY0Y8NAC3GY5XTWN12RG at 0250aef80fd573e96d189e8f0fee4ce5a6ec0b1f: the ambient-Node observation is correct, and it is intentional released behavior. Align #847, commit 8c1d7391b4b364c55fd454cacbf3fb97bb052c3a, explicitly removed this setup. Its managed workflow contract says the inline parser uses the runner image’s Node. I verified that source and the SRI-checked published 15.2.5 template; this PR adopts those exact bytes. The current-head commit-message job passed its metadata parser and title/subject checks. Restoring setup-node would reverse the shared released decision and create consumer drift. No consumer-specific change is needed; the existing shared documentation already states the dependency.

Review outcome for claim `01M5S7DY0Y8NAC3GY5XTWN12RG` at `0250aef80fd573e96d189e8f0fee4ce5a6ec0b1f`: the ambient-Node observation is correct, and it is intentional released behavior. [Align #847](https://code.j4k.dev/j4k/align/pulls/847), commit `8c1d7391b4b364c55fd454cacbf3fb97bb052c3a`, explicitly removed this setup. Its [managed workflow contract](https://code.j4k.dev/j4k/align/src/commit/8c1d7391b4b364c55fd454cacbf3fb97bb052c3a/docs/managed-workflows.md) says the inline parser uses the runner image’s Node. I verified that source and the SRI-checked published 15.2.5 template; this PR adopts those exact bytes. The current-head commit-message job passed its metadata parser and title/subject checks. Restoring setup-node would reverse the shared released decision and create consumer drift. No consumer-specific change is needed; the existing shared documentation already states the dependency.
jercik merged commit d5919ab2f6 into main 2026-10-25 10:03:21 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
j4k-oss/conventional-commit-msg!9
No description provided.