chore: upgrade to Vitest 5.1 and align with j4k-align 18.3.1 #19

jercik · 2026-11-05T17:14:13Z

jercik commented

2026-11-05 17:14:13 +00:00

Upgrades the tests to Vitest 5.1 and brings the repository to j4k-align 18.3.1.

vitest (and @vitest/coverage-v8 where present) moves to ^5.1.0. The tests needed no changes.
A new test:affected script runs pnpm run test --since-last-run: the same suite as test, limited to files affected by changes since the last run.
Align 18.3.1 refreshes the managed workflows and commit-message check. The baked-Node step now runs under bash, and the PR commit check now rejects unsquashed fixup!, squash! and amend! commits; the local hook still accepts them.

The commit hook ran the full local checks on both commits, and j4k-align audits clean.

Upgrades the tests to Vitest 5.1 and brings the repository to j4k-align 18.3.1. - `vitest` (and `@vitest/coverage-v8` where present) moves to `^5.1.0`. The tests needed no changes. - A new `test:affected` script runs `pnpm run test --since-last-run`: the same suite as `test`, limited to files affected by changes since the last run. - Align 18.3.1 refreshes the managed workflows and commit-message check. The baked-Node step now runs under bash, and the PR commit check now rejects unsquashed `fixup!`, `squash!` and `amend!` commits; the local hook still accepts them. The commit hook ran the full local checks on both commits, and `j4k-align` audits clean.

jercik added 2 commits

2026-11-05 17:14:13 +00:00

chore: upgrade to Vitest 5.1 ec251ae9a4

chore: align with j4k-align 18.3.1

Checks / reuse (pull_request) Has been skipped

Details

commit-msg / same-repo-pr (pull_request) Has been skipped

Details

commit-msg / commitlint (pull_request) Successful in 8s

Details

Checks / quality-checks (pull_request) Successful in 26s

Details

Checks / qc-result (pull_request) Has been skipped

Details

Dedupe check / dedupe-check (pull_request) Successful in 27s

Details

Review / Review (pull_request_target) Successful in 4m6s

Details

864612513d

forgejo-actions commented

2026-11-05 17:18:18 +00:00

Review 01M6PB8GJ22V6NGPAXG9RGDHZF — head 864612513dd42175af71927879e122741ddd87f5

Review — j4k-oss/askpplx @ `8401e464bd`

Scope: diff against base tree 79e3d6fe572e
Review finished: 6 succeeded, 0 failed, 4 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)

medium — The baked-Node check is pasted byte-for-byte into three workflows, so this change had to edit all three copies the same way

claim: 01M6PBB6NQ6CAF550C82777YBX
anchor: .forgejo/workflows/checks.yml (snippet)

      - name: Require the job image's baked Node
        shell: bash
        env:
          REQUIRED_NODE_VERSION_FILE: ".node-version"

lens: aposd-plain · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M6PBBTZCV9Y92KJK0SWARW87 · valid: Grounded excerpt (exact match) confirms the step header and REQUIRED_NODE_VERSION_FILE env in checks.yml. The reviewer gives a specific trace: the 22-line step appears in checks.yml 184-205, dedupe-check.yml 82-103, and release.yml 128-149, diff across them prints nothing, and this change made the same three edits (shell: bash, removal of the REQUIRED_NODE_VERSION either-or branch, regex replacing the case glob) in each copy. That is internally consistent and shows the APoSD Repetition red flag (a nontrivial block repeated) and Information Leakage (one policy, covering exact-version format, tool-cache path, and remediation text, encoded in three modules). The cost already lands on present code because this diff had to edit all three copies in lockstep, so the claim is in scope and medium fits. The secondary point also holds as stated: after the change the env var no longer selects a mode, and the step names '.node-version' separately from setup-node's node-version-file, with nothing tying them together. Remaining uncertainty: the remediation text mentions j4k-align. If these workflows are rendered from an alignment template, the dedup belongs in that template rather than here. The batch gives no evidence of that, and it would move where the fix goes, not whether the defect exists. The proposed remedy (a shared script under scripts/, like scripts/check-msg.sh, or a composite action that takes the version file as input) is proportionate.
disposition: none

The "Require the job image's baked Node" step is a 22-line policy check. It lives as three identical copies in .forgejo/workflows/checks.yml, dedupe-check.yml, and release.yml. In this change every copy got the same edit: add shell: bash, delete the REQUIRED_NODE_VERSION / REQUIRED_NODE_VERSION_FILE either-or branch, and replace the case glob with [[ $version =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]. Running diff on the step ranges (checks.yml 184-205, dedupe-check.yml 82-103, release.yml 128-149) prints nothing. The policy covers which version strings count as exact, where the tool cache lives (${RUNNER_TOOL_CACHE:-/opt/hostedtoolcache}/node/$version/x64.complete), and the remediation text that points at j4k-align and j4k/cluster node_ci_node_versions. Each future change to it has to land three times, and one missed copy leaves that workflow on different rules with no error.

Each copy also states the version file twice: once in this step's REQUIRED_NODE_VERSION_FILE: ".node-version", and again in the next step's node-version-file: ".node-version" for actions/setup-node@v6. The check only protects setup-node if both name the same file, and nothing ties the two together. After this change the env var no longer picks between modes, so it and the pin="$REQUIRED_NODE_VERSION_FILE" alias are leftover indirection. They suggest the step can be configured, but every copy uses one fixed value.

Correction: put the check in one place, either a script under scripts/ (the repo already does this with scripts/check-msg.sh) or a local composite action. Have it take the version file as its only input, and pass that same value to setup-node's node-version-file. That makes one module own the policy, and each workflow has a single line to change.

What I examined: the full step and the setup-node step that follows it in all three workflow files in the tree, plus the diff hunks for those files. I found no .forgejo/actions directory and no shared script for this check. I can't confirm from here whether Forgejo Actions on this runner resolves local composite actions. If it doesn't, the shared-script option still applies.

Other claims

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

Coverage

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

lens	part	arm	unit status	runs	loss
general-bug	whole	default	no-claims	1	no
writing-quality	whole	default	no-claims	1	no
restated-sets	whole	default	no-claims	1	no
unix-cli	shell-scripts	default	no-claims	1	no
module-design	whole	default	no-claims	1	no
aposd-plain	whole	default	claims-emitted	1	no

test-trimming — skipped-by-dispatch: no test files changed
project-docs — skipped-by-dispatch: no project documentation changed
use-effect — skipped-by-dispatch: no React or Effect code changed
react — skipped-by-dispatch: no React components changed

**Review** `01M6PB8GJ22V6NGPAXG9RGDHZF` — head `864612513dd42175af71927879e122741ddd87f5` # Review — j4k-oss/askpplx @ 8401e464bd9e Scope: diff against base tree `79e3d6fe572e` Review finished: 6 succeeded, 0 failed, 4 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) ### medium — The baked-Node check is pasted byte-for-byte into three workflows, so this change had to edit all three copies the same way - claim: `01M6PBB6NQ6CAF550C82777YBX` - anchor: `.forgejo/workflows/checks.yml` (snippet) ``` - name: Require the job image's baked Node shell: bash env: REQUIRED_NODE_VERSION_FILE: ".node-version" ``` - lens: aposd-plain · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M6PBBTZCV9Y92KJK0SWARW87` · valid: Grounded excerpt (exact match) confirms the step header and REQUIRED_NODE_VERSION_FILE env in checks.yml. The reviewer gives a specific trace: the 22-line step appears in checks.yml 184-205, dedupe-check.yml 82-103, and release.yml 128-149, diff across them prints nothing, and this change made the same three edits (shell: bash, removal of the REQUIRED_NODE_VERSION either-or branch, regex replacing the case glob) in each copy. That is internally consistent and shows the APoSD Repetition red flag (a nontrivial block repeated) and Information Leakage (one policy, covering exact-version format, tool-cache path, and remediation text, encoded in three modules). The cost already lands on present code because this diff had to edit all three copies in lockstep, so the claim is in scope and medium fits. The secondary point also holds as stated: after the change the env var no longer selects a mode, and the step names '.node-version' separately from setup-node's node-version-file, with nothing tying them together. Remaining uncertainty: the remediation text mentions j4k-align. If these workflows are rendered from an alignment template, the dedup belongs in that template rather than here. The batch gives no evidence of that, and it would move where the fix goes, not whether the defect exists. The proposed remedy (a shared script under scripts/, like scripts/check-msg.sh, or a composite action that takes the version file as input) is proportionate. - disposition: none > The "Require the job image's baked Node" step is a 22-line policy check. It lives as three identical copies in `.forgejo/workflows/checks.yml`, `dedupe-check.yml`, and `release.yml`. In this change every copy got the same edit: add `shell: bash`, delete the `REQUIRED_NODE_VERSION` / `REQUIRED_NODE_VERSION_FILE` either-or branch, and replace the `case` glob with `[[ $version =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]`. Running `diff` on the step ranges (checks.yml 184-205, dedupe-check.yml 82-103, release.yml 128-149) prints nothing. The policy covers which version strings count as exact, where the tool cache lives (`${RUNNER_TOOL_CACHE:-/opt/hostedtoolcache}/node/$version/x64.complete`), and the remediation text that points at j4k-align and `j4k/cluster node_ci_node_versions`. Each future change to it has to land three times, and one missed copy leaves that workflow on different rules with no error. > > Each copy also states the version file twice: once in this step's `REQUIRED_NODE_VERSION_FILE: ".node-version"`, and again in the next step's `node-version-file: ".node-version"` for `actions/setup-node@v6`. The check only protects setup-node if both name the same file, and nothing ties the two together. After this change the env var no longer picks between modes, so it and the `pin="$REQUIRED_NODE_VERSION_FILE"` alias are leftover indirection. They suggest the step can be configured, but every copy uses one fixed value. > > Correction: put the check in one place, either a script under `scripts/` (the repo already does this with `scripts/check-msg.sh`) or a local composite action. Have it take the version file as its only input, and pass that same value to setup-node's `node-version-file`. That makes one module own the policy, and each workflow has a single line to change. > > What I examined: the full step and the setup-node step that follows it in all three workflow files in the tree, plus the diff hunks for those files. I found no `.forgejo/actions` directory and no shared script for this check. I can't confirm from here whether Forgejo Actions on this runner resolves local composite actions. If it doesn't, the shared-script option still applies. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (0) ## Coverage Coverage pass: 01M6PB8GJ6C7JJ6AA34N6XTSPB Accounting: complete (all slots terminal; see slot results for failures) Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | general-bug | whole | default | no-claims | 1 | no | | writing-quality | whole | default | no-claims | 1 | no | | restated-sets | whole | default | no-claims | 1 | no | | unix-cli | shell-scripts | default | no-claims | 1 | no | | module-design | whole | default | no-claims | 1 | no | | aposd-plain | whole | default | claims-emitted | 1 | no | - test-trimming — skipped-by-dispatch: no test files changed - project-docs — skipped-by-dispatch: no project documentation changed - use-effect — skipped-by-dispatch: no React or Effect code changed - react — skipped-by-dispatch: no React components changed

🚀 1

forgejo-actions reviewed

2026-11-05 17:18:18 +00:00

.forgejo/workflows/checks.yml

Lines 184-187

					
				@ -182,26 +182,18 @@ jobs:

				        uses: pnpm/action-setup@v5

				      - name: Require the job image's baked Node

				        shell: bash

				        env:

				          REQUIRED_NODE_VERSION_FILE: ".node-version"

medium — The baked-Node check is pasted byte-for-byte into three workflows, so this change had to edit all three copies the same way

The "Require the job image's baked Node" step is a 22-line policy check. It lives as three identical copies in .forgejo/workflows/checks.yml, dedupe-check.yml, and release.yml. In this change every copy got the same edit: add shell: bash, delete the REQUIRED_NODE_VERSION / REQUIRED_NODE_VERSION_FILE either-or branch, and replace the case glob with [[ $version =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]. Running diff on the step ranges (checks.yml 184-205, dedupe-check.yml 82-103, release.yml 128-149) prints nothing. The policy covers which version strings count as exact, where the tool cache lives (${RUNNER_TOOL_CACHE:-/opt/hostedtoolcache}/node/$version/x64.complete), and the remediation text that points at j4k-align and j4k/cluster node_ci_node_versions. Each future change to it has to land three times, and one missed copy leaves that workflow on different rules with no error.

Each copy also states the version file twice: once in this step's REQUIRED_NODE_VERSION_FILE: ".node-version", and again in the next step's node-version-file: ".node-version" for actions/setup-node@v6. The check only protects setup-node if both name the same file, and nothing ties the two together. After this change the env var no longer picks between modes, so it and the pin="$REQUIRED_NODE_VERSION_FILE" alias are leftover indirection. They suggest the step can be configured, but every copy uses one fixed value.

Correction: put the check in one place, either a script under scripts/ (the repo already does this with scripts/check-msg.sh) or a local composite action. Have it take the version file as its only input, and pass that same value to setup-node's node-version-file. That makes one module own the policy, and each workflow has a single line to change.

What I examined: the full step and the setup-node step that follows it in all three workflow files in the tree, plus the diff hunks for those files. I found no .forgejo/actions directory and no shared script for this check. I can't confirm from here whether Forgejo Actions on this runner resolves local composite actions. If it doesn't, the shared-script option still applies.

lens aposd-plain · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M6PBB6NQ6CAF550C82777YBX of review 01M6PB8GJ22V6NGPAXG9RGDHZF

**medium** — The baked-Node check is pasted byte-for-byte into three workflows, so this change had to edit all three copies the same way > The "Require the job image's baked Node" step is a 22-line policy check. It lives as three identical copies in `.forgejo/workflows/checks.yml`, `dedupe-check.yml`, and `release.yml`. In this change every copy got the same edit: add `shell: bash`, delete the `REQUIRED_NODE_VERSION` / `REQUIRED_NODE_VERSION_FILE` either-or branch, and replace the `case` glob with `[[ $version =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]`. Running `diff` on the step ranges (checks.yml 184-205, dedupe-check.yml 82-103, release.yml 128-149) prints nothing. The policy covers which version strings count as exact, where the tool cache lives (`${RUNNER_TOOL_CACHE:-/opt/hostedtoolcache}/node/$version/x64.complete`), and the remediation text that points at j4k-align and `j4k/cluster node_ci_node_versions`. Each future change to it has to land three times, and one missed copy leaves that workflow on different rules with no error. > > Each copy also states the version file twice: once in this step's `REQUIRED_NODE_VERSION_FILE: ".node-version"`, and again in the next step's `node-version-file: ".node-version"` for `actions/setup-node@v6`. The check only protects setup-node if both name the same file, and nothing ties the two together. After this change the env var no longer picks between modes, so it and the `pin="$REQUIRED_NODE_VERSION_FILE"` alias are leftover indirection. They suggest the step can be configured, but every copy uses one fixed value. > > Correction: put the check in one place, either a script under `scripts/` (the repo already does this with `scripts/check-msg.sh`) or a local composite action. Have it take the version file as its only input, and pass that same value to setup-node's `node-version-file`. That makes one module own the policy, and each workflow has a single line to change. > > What I examined: the full step and the setup-node step that follows it in all three workflow files in the tree, plus the diff hunks for those files. I found no `.forgejo/actions` directory and no shared script for this check. I can't confirm from here whether Forgejo Actions on this runner resolves local composite actions. If it doesn't, the shared-script option still applies. lens `aposd-plain` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M6PBB6NQ6CAF550C82777YBX` of review `01M6PB8GJ22V6NGPAXG9RGDHZF`

👎 1

Not a defect in this PR. These workflows are rendered by j4k-align, and j4k-align --fix overwrites hand edits, so the three copies can't drift apart here. The step's script has one source, src/template-scripts/baked-node-check-script.ts, which every template inserts with {{templateScript "baked-node-version-file-check" 10}}. The Align audit reports any rendered copy that differs from it. REQUIRED_NODE_VERSION_FILE and pin aren't leftovers: the same script also runs in inline-version mode (REQUIRED_NODE_VERSION) in the credential-contract workflow. src/workflow-baked-node.test.ts checks, for every template, that the guard's env names the same input as the setup-node step after it.

Not a defect in this PR. These workflows are rendered by j4k-align, and `j4k-align --fix` overwrites hand edits, so the three copies can't drift apart here. The step's script has one source, [`src/template-scripts/baked-node-check-script.ts`](https://code.j4k.dev/j4k/align/src/branch/main/src/template-scripts/baked-node-check-script.ts), which every template inserts with `{{templateScript "baked-node-version-file-check" 10}}`. The Align audit reports any rendered copy that differs from it. `REQUIRED_NODE_VERSION_FILE` and `pin` aren't leftovers: the same script also runs in inline-version mode (`REQUIRED_NODE_VERSION`) in the credential-contract workflow. [`src/workflow-baked-node.test.ts`](https://code.j4k.dev/j4k/align/src/branch/main/src/workflow-baked-node.test.ts) checks, for every template, that the guard's env names the same input as the `setup-node` step after it.

jercik marked this conversation as resolved

jercik merged commit 95df258415 into main

2026-11-05 17:41:36 +00:00

jercik deleted branch chore/vitest-5-1

2026-11-05 17:41:36 +00:00

jercik referenced this pull request from a commit

2026-11-05 17:41:38 +00:00

chore: upgrade to Vitest 5.1 and align with j4k-align 18.3.1 (#19)

Sign in to join this conversation.

No reviewers

No labels

No milestone