ci: harden NeuralOS verification workflow - #7
Conversation
| exit 1 | ||
| fi | ||
| echo "path=$EXE" >> "$GITHUB_OUTPUT" | ||
| echo "name=$(basename $EXE)" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
🔴 Unquoted $EXE in basename produces wrong artifact name due to space in filename
The artifact name pattern in package.json:116 is forgecore-os ${version}.exe, which resolves to e.g. forgecore-os 2.0.0.exe (containing a space). On line 65, basename $EXE is called without quoting $EXE. Shell word-splitting will split dist/forgecore-os 2.0.0.exe into two arguments: dist/forgecore-os and 2.0.0.exe. basename interprets two arguments as basename NAME SUFFIX, so it returns forgecore-os (ignoring the second arg since it's not a matching suffix) instead of the full forgecore-os 2.0.0.exe. This causes the release body to display an incorrect artifact name.
| echo "name=$(basename $EXE)" >> "$GITHUB_OUTPUT" | |
| echo "name=$(basename "$EXE")" >> "$GITHUB_OUTPUT" |
Was this helpful? React with 👍 or 👎 to provide feedback.
- Add playwright.config.ts with CI-tuned workers, retries, reporters, and trace-on-failure - Add parallel CI jobs: e2e-tests (runs 23 Playwright tests) and lint (runs ESLint) alongside the existing build-portable job - Replace ancient Tauri release workflow with Electron-based pipeline: build portable, sign manifest, verify hash chain, publish as GitHub Release with SHA-256 in the body — triggered by v* tags - Set up husky + lint-staged at repo root: ESLint --fix and Prettier run automatically on every commit for NeuralOS_Master_Build files - Install eslint, prettier, husky, lint-staged as root devDependencies 🤖 Generated with [Qoder][https://qoder.com]
59b3cca to
7569b6d
Compare
fa5a611 to
839d561
Compare
| - name: Use Node.js | ||
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: "20" |
There was a problem hiding this comment.
🟡 Release workflow uses Node 20 while CI tests with Node 22.12.0
The CI workflow (forgecore-ci.yml:18) consistently uses node-version: "22.12.0" for all three jobs, but the new release workflow (release.yml:21) uses node-version: "20". The release workflow runs the same scripts (build:portable, verify:portable, verify:release, release_portable.cjs) that CI tests with Node 22. If any of these scripts use Node 22-specific APIs or behavior, the release build will fail even though CI passes. The release pipeline should use the same Node version that CI validates against.
| node-version: "20" | |
| node-version: "22.12.0" | |
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
CI status
Root causes fixed
Test plan
Follow-up (not blocking merge)
🤖 Generated with Claude Code