Conversation
Use a shared Node 24 build baseline while testing Node 22 and 24. Add frontend and actionlint gates, pin Noble lint runners, and schedule UI dependency updates. Refs DeusData#2108 Signed-off-by: Rares Popa <2606875+rarepops@users.noreply.github.com>
|
Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. Current review status: working through a backlog. What that means for this PR, concretely:
Things that will genuinely speed it up whenever review does happen:
If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. |
Call the exact actions/attest implementation already used by the deprecated wrapper, preserving inputs, defaults, and Node options. Match the diagnostics runner to its Noble LLVM package source. Refs DeusData#2108 Signed-off-by: Rares Popa <2606875+rarepops@users.noreply.github.com>
CI run 34255410324: Windows daemon guard recurrenceRun at 840de91 completed with one primary failed job: test / test-windows-guards. The ci-ok failure is the expected downstream propagation. Passing hosted checks include both frontend Node 22/24 jobs, all four package-wrapper matrix jobs, all three lint jobs, security gates, Unix/Windows C shards, sanitizer lanes (diagnostics/MSan/LSan/TSan), and shard completeness. Seven of the eight native Windows guard scripts also passed. The failures are both in tests/windows/test_daemon_stability.py:
These symptoms match the pre-existing reports in #2057. I also checked the independent September 6 job directly: it prints the identical cold-storm endpoint refusal for client 2. Comparing upstream base 161df2b with this head confirms src/, internal/, tests/windows/, and scripts/test-windows.ps1 are unchanged by this PR. The current stability guard already sets a per-section CBM_RUNTIME_DIR, so the older issue description alone is not enough to establish the remaining cause. This report records the recurrence; it does not claim a proven timeout or isolation fix. No retries, timeout increases, skips, or weakened assertions have been added. The root cause remains tracked separately in #2057. |
DeusData
added
enhancement
|
Thank you for contributing the Node and validation updates, and for documenting the Windows-guard recurrence without weakening the guard. This touches build, test and release workflows as well as contributor guidance, so we need more time to review the scope and release implications before giving a decision. The review queue is currently full, so detailed feedback may take a little time. We are working through it carefully and appreciate the work you have put into supporting the project. Thank you for your patience. |
|
You are owed a decision, and here it is — with an apology for the eleven days it took. On 2026-09-09 we said we needed more time to review the scope; the ball was ours the whole time, and the acknowledgement bot on this thread promises we would not close it for inactivity. We meant that. First, the thing that deserves saying plainly: when your CI went red you reported it yourself, diagnosed it as pre-existing #2057, corroborated it against an independent job from 2026-09-06, and proved non-causation by diffing base against head to show Decision: two slices taken now, in #2249, with Taken:
Declined, and why:
#2109 stays open and is yours to decide. If you would like to rework it down to the actionlint job re-sited off the critical path, that is a contribution I would welcome and review promptly. If you would rather close it now that the two best pieces have landed, say so and I will close it with thanks. Either is a good outcome; what I did not want was to close it while the only outstanding action was ours. |
…wrapper Distilled from #2109 by Rares Popa. Two slices only; the rest of that PR is either frontend work the UI rebuild makes redundant, or a gating change that needs re-siting first. 1. Three jobs move from ubuntu-latest to ubuntu-24.04 _lint.yml `lint` and `lint-mem`, and _test.yml `test-diag`, each install a toolchain from an apt.llvm.org repo whose name contains the release: deb http://apt.llvm.org/noble/ llvm-toolchain-noble-20 main deb http://apt.llvm.org/noble/ llvm-toolchain-noble-21 main noble IS 24.04. So these jobs already depend on a specific release while asking for whatever ubuntu-latest happens to mean that morning. The day GitHub advances ubuntu-latest, all three break at once, on a schedule nobody here chose, and the failure surfaces as an apt error far from its cause. Pinning the runner to the release the repo line already names costs nothing and removes the trapdoor. 2. actions/attest-sbom -> actions/attest attest-sbom is deprecated. Its remaining behaviour is to print "::warning::actions/attest-sbom has been deprecated" and forward to actions/attest with NODE_OPTIONS set, passing sbom-path through unchanged. Calling attest directly yields the same attestation minus the wrapper. Verified rather than assumed, because this sits on the release path: 59d89421af93a897026c735860bf21b6eb4f7b26 is exactly tag v4.1.0 of actions/attest, and sbom-path is a real input on that action at that SHA. The step keeps no continue-on-error, so a failed SBOM attestation still fails the release. That is the intended behaviour and the comment now says so: an unattested SBOM is worse than an absent one, because the artifact ships looking complete. Deliberately NOT taken from #2109, each for its own reason: - the actionlint job, as sited. _lint.yml is consumed by pr.yml, dry-run.yml and release.yml, pr.yml gates its whole test stage on `if lint succeeded`, and release.yml gates build on needs.lint.result == 'success'. A job there is merge-blocking and release-blocking with no branch-protection edit to make it visible, and this one curls a tarball from github.com releases with no cache and no fallback. actionlint is worth having; not on that path, and not before it has been run against current main. - the test-package-wrappers node matrix. It reruns the Go and PyPI suites a second time per OS to vary a Node version only the npm leg reads. - everything frontend: the test-frontend job, .node-version, and the dependabot graph-ui block. The UI is being rebuilt from the ground up, so gating on the current one buys coverage of a surface that is going away. Co-authored-by: Rares Popa <2606875+rarepops@users.noreply.github.com> Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
2 participants
What does this PR do?
Closes #2108.
This draft implements the CI maintenance proposal while awaiting maintainer feedback on its scope. Node 22 is still supported; this is not a blanket action-runtime deprecation update.
Existing C/sanitizer coverage, SHA-pinning policy, token permissions, release gate ordering, and supported platforms remain intact. No application dependency versions are changed.
Validation
Passed locally on Windows:
Not run locally: the full C test suite, C lint, Go/PyPI wrapper suites, and hosted cross-platform/release jobs. The existing hosted gates remain enabled; maintainer approval to run fork CI may be required. The frontend build still reports its existing bundle-size warning.
Broader CI audit (2026-09-08)
The follow-up in 840de91 is based on workflow annotations and action metadata, not just action version labels:
The follow-up passes actionlint and the venue-parity/release-gate contracts. Actual hosted SBOM attestation remains a release-only check and was not triggered locally.
Checklist