feat(release): validate multi-architecture Community installs - #51
feat(release): validate multi-architecture Community installs#51mohit-nagaraj wants to merge 4 commits into
Conversation
Signed-off-by: Mohit Nagaraj <mohitnagaraj20@gmail.com>
|
Warning Review limit reachedNext included review available in 47 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR adds checksum verification to shell and npm installers, parameterizes Docker Compose deployments, updates CLI runtime checks, and introduces candidate and published multi-architecture community release smoke tests with evidence collection. ChangesCommunity release validation
Estimated code review effort: 4 (Complex) | ~60 minutes Merge Risk: 🔴 Critical · up to This PR changes release installation and multi-architecture validation, but the current implementation can reject valid published releases, fail on supported Node.js versions, hang during startup, misroute browser requests or collide across concurrent Compose runs, and still allow a compromised download path to provide a matching binary and checksum. These release-blocking correctness, availability, compatibility, and supply-chain risks should be fixed before merge. Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant Installer
participant OrchCLI
participant DockerCompose
participant PlaywrightCLI
GitHubActions->>Installer: Install and verify CLI release asset
GitHubActions->>OrchCLI: Run init, start, and status
OrchCLI->>DockerCompose: Generate and start configured stack
DockerCompose-->>OrchCLI: Report service health
OrchCLI->>PlaywrightCLI: Run browser request against UI
PlaywrightCLI-->>GitHubActions: Upload smoke evidence
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Linked Issues checkExplanation The changes implement the coding requirements in issue Full details: Out of Scope Changes checkExplanation Most changes support issue Full details: Docstring CoverageExplanation Docstring coverage is 15.15% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 33 functions across 8 files. (16 skipped: 16 unsupported.) ✨ Finishing Touches 💡 2📝 Generate docstrings 💡
🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Signed-off-by: Mohit Nagaraj <mohitnagaraj20@gmail.com>
Signed-off-by: Mohit Nagaraj <mohitnagaraj20@gmail.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (2)
.github/scripts/community-smoke.sh (1)
107-110: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueRemove the temporary directory in one step.
project_dircomes frommktemp -d, so the whole tree is safe to delete. The current cleanup deletes onlyproject.jsonanddocker/*.yml, sormdirfails wheneverorchcli initwrites any other file, and the temporary directory leaks. This matters most for local runs, where the leaked directories accumulate.♻️ Proposed simplification
- rm -f "$project_dir/.kubeorch/project.json" - rmdir "$project_dir/.kubeorch" >/dev/null 2>&1 || true - rm -f "$project_dir/docker/"*.yml - rmdir "$project_dir/docker" "$project_dir/scripts" "$project_dir" >/dev/null 2>&1 || true + rm -rf "$project_dir".github/workflows/community-smoke.yml (1)
91-98: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAssert that the installer performed checksum verification.
The step is named "Verify native installer and checksum", but the assertions only cover the reported version and the
filearchitecture string. Neither proves thatinstall.shdownloadedchecksums.txtand compared the SHA256 value. A regression that silently skips verification would still pass this job.Capture the installer output and assert its verification message.
♻️ Proposed change
ORCHCLI_VERSION="$SMOKE_CLI_VERSION" \ ORCHCLI_INSTALL_DIR="$install_dir" \ ORCHCLI_NO_SUDO=1 \ - sh ./install.sh + sh ./install.sh 2>&1 | tee native-install.log "$install_dir/${{ matrix.binary }}" --version | tee native-version.log file "$install_dir/${{ matrix.binary }}" | tee native-binary.log grep -F "OrchCLI ${SMOKE_CLI_VERSION#v}" native-version.log grep -F "${{ matrix.file_pattern }}" native-binary.log + # Replace the pattern below with the exact message install.sh emits after verification. + grep -Fi "checksum" native-install.logAdd
native-install.logto the uploaded artifact list at lines 126-130.Run the following script to confirm the exact message that
install.shprints after verification:#!/bin/bash # Description: Show the checksum verification output emitted by install.sh. set -euo pipefail rg -nPi 'checksum|sha256|shasum|verif' install.sh
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Team
Run ID: ed9d0302-fdde-4db7-945b-52ce39bea58c
📒 Files selected for processing (24)
.gitattributes.github/scripts/community-smoke.sh.github/workflows/community-smoke.yml.github/workflows/release-and-publish.yml.gitignoreREADME.mdcmd/docker/docker-compose.dev.ymlcmd/docker/docker-compose.hybrid-core.ymlcmd/docker/docker-compose.hybrid-ui.ymlcmd/docker/docker-compose.prod.ymlcmd/init.gocmd/runtime_contract_test.gocmd/start.gocmd/status.godocker/docker-compose.dev.ymldocker/docker-compose.hybrid-core.ymldocker/docker-compose.hybrid-ui.ymldocker/docker-compose.prod.ymldocs/ARCHITECTURE.mddocs/COMMUNITY-SMOKE.mdinstall.shnpm/scripts/postinstall.jsnpm/scripts/postinstall.test.jspackage.json
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.
| grep -Fqx "$core_image" "$evidence_dir/compose-images.log" | ||
| grep -Fqx "$ui_image" "$evidence_dir/compose-images.log" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🔴 Critical | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
#!/bin/bash
# Description: Resolve the CLI-embedded Core/UI image defaults used by generated production Compose.
set -euo pipefail
# Find the default image constants.
rg -nP '\b(defaultCoreImage|defaultUIImage)\b' --type=go -C 3
# Show how the production Compose template references them.
fd -t f 'docker-compose.prod.yml' | while IFS= read -r file; do
echo "== $file"
rg -n 'KUBEORCH_(CORE|UI)_IMAGE' "$file"
doneRepository: KubeOrch/cli
Length of output: 150
🏁 Script executed:
#!/bin/bash
set -u
echo '== community-smoke.sh relevant section =='
sed -n '130,195p' .github/scripts/community-smoke.sh
echo '== default image definitions and references =='
rg -n -P '\b(defaultCoreImage|defaultUIImage|KUBEORCH_CORE_IMAGE|KUBEORCH_UI_IMAGE)\b' \
--glob '*.go' --glob '*.yml' --glob '*.yaml' --glob '*.sh' . \
| head -n 200
echo '== compose template candidates =='
git ls-files | rg '(^|/)(docker-compose[^/]*\.ya?ml|.*compose.*\.ya?ml)$' \
| head -n 100Repository: KubeOrch/cli
Length of output: 5196
🏁 Script executed:
#!/bin/bash
set -u
echo '== smoke mode and image inputs =='
sed -n '1,130p' .github/scripts/community-smoke.sh
echo '== init implementation and compose selection =='
sed -n '1,190p' cmd/init.go
echo '== production compose image entries =='
sed -n '25,60p' cmd/docker/docker-compose.prod.yml
echo '== runtime contract assertions =='
sed -n '285,320p' cmd/runtime_contract_test.goRepository: KubeOrch/cli
Length of output: 12828
Use mode-specific image expectations in published mode.
Published mode unsets KUBEORCH_CORE_IMAGE and KUBEORCH_UI_IMAGE, so orchcli init uses the embedded defaults. The checks at lines 184-185 compare those defaults with the operator-supplied $core_image and $ui_image, causing the smoke to exit before orchcli start when they differ. Use the embedded defaults for published-mode checks and report mismatches clearly.
|
|
||
| - name: Set up Go | ||
| uses: actions/setup-go@v5 | ||
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6.2.0 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
#!/bin/sh
set -eu
repo=actions/setup-go
tag=v6.2.0
pinned=924ae3a1cded613372ab5595356fb5720e22ba16
echo "tag ref:"
gh api "repos/$repo/git/refs/tags/$tag" --jq '{type: .object.type, sha: .object.sha}'
tag_object="$(gh api "repos/$repo/git/refs/tags/$tag" --jq '.object.sha')"
tag_type="$(gh api "repos/$repo/git/refs/tags/$tag" --jq '.object.type')"
if [ "$tag_type" = tag ]; then
echo "dereferenced tag:"
gh api "repos/$repo/git/tags/$tag_object" --jq '{type: .object.type, sha: .object.sha}'
resolved="$(gh api "repos/$repo/git/tags/$tag_object" --jq '.object.sha')"
else
resolved="$tag_object"
fi
echo "resolved v6.2.0 commit:"
gh api "repos/$repo/commits/$resolved" --jq '.sha'
echo "pinned commit:"
gh api "repos/$repo/commits/$pinned" --jq '.sha'
echo "pinned commit metadata:"
gh api "repos/$repo/commits/$pinned" --jq '{sha: .sha, message: (.commit.message | split("\n")[0])}'
echo "local workflow line:"
sed -n '20,27p' .github/workflows/release-and-publish.ymlRepository: KubeOrch/cli
Length of output: 741
🏁 Script executed:
#!/bin/sh
set -eu
repo=actions/setup-go
tag=v6.5.0
pinned=924ae3a1cded613372ab5595356fb5720e22ba16
ref="$(gh api "repos/$repo/git/refs/tags/$tag" --jq '.object | "\(.type) \(.sha)"')"
echo "tag ref: $ref"
type="${ref%% *}"
object="${ref#* }"
if [ "$type" = tag ]; then
resolved="$(gh api "repos/$repo/git/tags/$object" --jq '.object.sha')"
else
resolved="$object"
fi
echo "resolved v6.5.0 commit: $resolved"
echo "pinned commit: $(gh api "repos/$repo/commits/$pinned" --jq '.sha')"
[ "$resolved" = "$pinned" ]Repository: KubeOrch/cli
Length of output: 328
Correct the actions/setup-go version annotation.
The pinned SHA 924ae3a1cded613372ab5595356fb5720e22ba16 resolves to v6.5.0, not v6.2.0. Update the annotation to v6.5.0, or replace the SHA with the verified v6.2.0 commit 7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5.
🧰 Tools
🪛 zizmor (1.29.0)
[error] 24-24: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default
(cache-poisoning)
Source: MCP tools
| uses: actions/setup-go@v5 | ||
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6.2.0 | ||
| with: | ||
| go-version: '1.22' |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- workflow ---'
cat -n .github/workflows/release-and-publish.yml | sed -n '1,180p'
printf '%s\n' '--- repository version and dependency files ---'
git ls-files | grep -E '(^|/)(package\.json|package-lock\.json|npm-shrinkwrap\.json|yarn\.lock|pnpm-lock\.yaml|\.nvmrc|\.node-version|go\.mod|go\.work|\.tool-versions)$' || trueRepository: KubeOrch/cli
Length of output: 6104
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- package.json ---'
cat -n package.json
printf '%s\n' '--- go.mod ---'
cat -n go.modRepository: KubeOrch/cli
Length of output: 2361
🌐 Web query:
actions/setup-go go-version 1.22 semver patch version resolution documentation actions/setup-node node-version 24 semver range documentation
💡 Result:
The actions/setup-go and actions/setup-node actions utilize the npm semver package for version resolution, allowing for flexible version specification [1][2][3][4]. Below is a synthesis of their documentation regarding version resolution and patch behavior. actions/setup-go The go-version input supports SemVer range syntax (e.g., ^1.25.1, ~1.24.1, >=1.22.0) and specific version strings [2][5][6]. Version Resolution: 1. Local Cache: The action checks the runner's local tool cache for a version satisfying the SemVer specification [2][5][6]. 2. Manifest: If not found, it checks the actions/go-versions repository manifest [2][5][6]. 3. Direct Download: If the manifest lookup fails, it falls back to the official Go distribution site [2][5][6]. Patch Resolution & Latest-Patch Behavior: - Exact Pins: By default, versions are treated as exact pins [7]. - go-version-file-behavior: A newer input allows users to set this to latest-patch [7]. When used with a file like go.mod, it widens an exact major.minor.patch version into a ~X.Y.Z semver range [7]. This ensures the action resolves the newest available patch release of that minor version, effectively treating the file's version as a floor [7]. - Check-latest Input: When check-latest is set to true, the action bypasses the local cache to fetch the latest available version from the manifest that satisfies the provided range [6]. actions/setup-node The node-version input also follows SemVer specification [3][4]. Version Resolution: - The action supports SemVer ranges and specific versions [3][4]. - Aliases: It supports specific aliases such as lts/*, latest, current, and nightly builds [3][4][8]. - Check-latest Input: When check-latest is false (default), the action prefers the locally cached version that satisfies the spec [3][9]. If set to true, it fetches the latest available version (for LTS ranges) from the actions/node-versions manifest or the Node.js distribution site [3][9]. General Notes: - Precedence: In both actions, if both the version input (go-version/node-version) and the file input (go-version-file/node-version-file) are provided, the explicit version input takes precedence [1][2][3][9]. - Recommendation: Wrapping version strings in single quotes (e.g., '1.22') is recommended in YAML to prevent parsers from misinterpreting the version (e.g., trimming 1.22 to 1.2) [5].
Citations:
- 1: https://github.com/actions/setup-go/blob/main/docs/advanced-usage.md
- 2: https://github.com/actions/setup-go/blob/main/README.md
- 3: https://github.com/actions/setup-node/blob/main/README.md
- 4: https://github.com/actions/setup-node
- 5: https://github.com/actions/setup-go
- 6: https://deepwiki.com/actions/setup-go/2.1-version-resolution
- 7: GitHub pull request 785 in actions/setup-go (link omitted to avoid creating a cross-reference)
- 8: https://github.com/marketplace/actions/setup-node-js-environment
- 9: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md
🏁 Script executed:
#!/bin/bash
set -eu
tmp="$(mktemp -d)"
curl -fsSL "https://raw.githubusercontent.com/actions/setup-go/924ae3a1cded613372ab5595356fb5720e22ba16/README.md" -o "$tmp/setup-go-readme.md"
curl -fsSL "https://raw.githubusercontent.com/actions/setup-go/924ae3a1cded613372ab5595356fb5720e22ba16/src/installer.ts" -o "$tmp/setup-go-installer.ts" || true
curl -fsSL "https://raw.githubusercontent.com/actions/setup-node/249970729cb0ef3589644e2896645e5dc5ba9c38/README.md" -o "$tmp/setup-node-readme.md"
printf '%s\n' '--- setup-go version documentation ---'
rg -n -i -C 4 'exact|patch|semver|go-version(-file)?|check-latest' "$tmp/setup-go-readme.md" | head -160
printf '%s\n' '--- setup-node version documentation ---'
rg -n -i -C 4 'exact|patch|semver|node-version(-file)?|check-latest' "$tmp/setup-node-readme.md" | head -160
printf '%s\n' '--- downloaded resolver candidates ---'
find "$tmp" -type f -maxdepth 1 -printRepository: KubeOrch/cli
Length of output: 10315
🏁 Script executed:
#!/bin/bash
set -eu
sha=924ae3a1cded613372ab5595356fb5720e22ba16
tmp="$(mktemp -d)"
for file in src/installer.ts src/manifest.ts src/semver.ts src/main.ts; do
url="https://raw.githubusercontent.com/actions/setup-go/$sha/$file"
if curl -fsSL "$url" -o "$tmp/$(basename "$file")"; then
printf '%s\n' "--- $file ---"
rg -n -i -C 5 'versionSpec|semver|resolve|findVersion|latest|patch|manifest' "$tmp/$(basename "$file")" | head -180
fi
doneRepository: KubeOrch/cli
Length of output: 9249
🏁 Script executed:
#!/bin/bash
set -eu
sha=924ae3a1cded613372ab5595356fb5720e22ba16
printf '%s\n' '--- setup-go installer resolver ---'
curl -fsSL "https://raw.githubusercontent.com/actions/setup-go/$sha/src/installer.ts" \
| nl -ba | sed -n '260,470p'
printf '%s\n' '--- setup-go input parser ---'
curl -fsSL "https://raw.githubusercontent.com/actions/setup-go/$sha/src/main.ts" \
| nl -ba | sed -n '145,190p'Repository: KubeOrch/cli
Length of output: 435
🏁 Script executed:
#!/bin/bash
set -eu
sha=924ae3a1cded613372ab5595356fb5720e22ba16
tmp="$(mktemp)"
curl -fsSL "https://raw.githubusercontent.com/actions/setup-go/$sha/src/installer.ts" > "$tmp"
printf '%s\n' '--- resolver functions ---'
grep -n -E 'function (getInfoFromManifest|resolveVersionFromManifest|makeSemver)|semver\.(satisfies|rcompare|lt)|versionSpec' "$tmp" | tail -80
printf '%s\n' '--- resolver context ---'
sed -n '300,440p' "$tmp"
rm -f "$tmp"Repository: KubeOrch/cli
Length of output: 6899
Pin exact Go and Node patch versions.
actions/setup-node treats node-version: '24' as a major-version selector. actions/setup-go resolves go-version: '1.22' through semver matching. Use exact patch versions, such as the go 1.22.2 value in go.mod, to keep release validation reproducible.
Source: MCP tools
| CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags "$LDFLAGS" -o dist/orchcli_linux_amd64 main.go | ||
| CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -ldflags "$LDFLAGS" -o dist/orchcli_linux_arm64 main.go | ||
| CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -ldflags "$LDFLAGS" -o dist/orchcli_windows_amd64.exe main.go | ||
| CGO_ENABLED=0 GOOS=windows GOARCH=arm64 go build -ldflags "$LDFLAGS" -o dist/orchcli_windows_arm64.exe main.go |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Document the Windows ARM64 release asset.
This change publishes dist/orchcli_windows_arm64.exe, but the release body at Line 124-125 documents only orchcli_windows_amd64.exe. Add Windows ARM64 download guidance so users can select the native artifact.
| cmd := exec.Command(args[0], args[1:]...) | ||
| cmd.Dir = projectPath | ||
| if err := cmd.Run(); err == nil { |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Bound each MongoDB readiness attempt.
exec.Command can wait indefinitely for Docker Compose. The 30-iteration loop only applies after each process exits. A blocked daemon or mongosh command can make orchcli start -d hang forever. Pass cmd.Context() into waitForMongoDB and use exec.CommandContext with a short per-attempt timeout.
As per PR objectives, service validation must use bounded time limits.
| - "3000" | ||
| environment: | ||
| KUBEORCH_MONGO_URI: mongodb://mongodb:27017/kubeorchestra | ||
| KUBEORCH_CORS_ALLOWED_ORIGINS: ${KUBEORCH_CORS_ALLOWED_ORIGINS:-http://localhost:3001} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Keep browser and API defaults aligned with overridden ports.
Changing KUBEORCH_CORE_PORT or KUBEORCH_UI_PORT does not update the default NEXT_PUBLIC_API_URL or KUBEORCH_CORS_ALLOWED_ORIGINS. A validation run that overrides either port without also supplying the paired URL or origin can call the wrong Core endpoint or fail CORS. Derive these defaults from the selected ports, or require and validate matching explicit values.
📍 Affects 2 files
docker/docker-compose.prod.yml#L43-L43(this comment)cmd/docker/docker-compose.prod.yml#L38-L38
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Scope explicit Compose resources to the selected project.
Setting KUBEORCH_COMPOSE_PROJECT does not namespace explicit container, network, volume, or host-port names. Concurrent or stale validation runs can therefore collide or reuse MongoDB data. Remove explicit names where possible, or derive every resource name and host port from the selected project.
📍 Affects 2 files
docker/docker-compose.prod.yml#L1-L1(this comment)cmd/docker/docker-compose.hybrid-core.yml#L4-L4
| if command -v curl >/dev/null 2>&1; then | ||
| curl -L -o "$TEMP_BINARY" "$DOWNLOAD_URL" || { | ||
| error "Failed to download binary" | ||
| rm -rf "$TEMP_DIR" | ||
| exit 1 | ||
| } | ||
| curl -fsSL --retry 3 --output "$destination" "$source_url" | ||
| elif command -v wget >/dev/null 2>&1; then | ||
| wget -q -O "$TEMP_BINARY" "$DOWNLOAD_URL" || { | ||
| error "Failed to download binary" | ||
| rm -rf "$TEMP_DIR" | ||
| exit 1 | ||
| } | ||
| wget -q -O "$destination" "$source_url" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
sed -n '120,180p;185,220p;290,315p' install.shRepository: KubeOrch/cli
Length of output: 3746
Security Misconfiguration (CWE-319): Cleartext Transmission of Sensitive Information
Reachability: External · Exploitability: Difficult
Keep every release-download redirect on HTTPS.
Both download branches follow redirects without restricting the redirect scheme. An attacker who controls an HTTP redirect target can replace both files, causing the checksum comparison to pass. Restrict curl redirects with --proto '=https' --proto-redir '=https', or remove the Wget fallback unless it enforces HTTPS for every redirect.
| fs.mkdirSync(binDir, { recursive: true }); | ||
| } | ||
| fs.mkdirSync(binDir, { recursive: true }); | ||
| fs.rmSync(temporaryPath, { force: true }); |
There was a problem hiding this comment.
🩺 Stability & Availability | 🔴 Critical | 🏗️ Heavy lift
🔎 Supported by static analysis
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- package.json ---'
cat -n package.json | sed -n '1,35p'
printf '%s\n' '--- npm/scripts/postinstall.js (imports and cleanup) ---'
sed -n '1,35p' npm/scripts/postinstall.js
sed -n '175,215p' npm/scripts/postinstall.js
printf '%s\n' '--- npm/scripts/postinstall.test.js ---'
cat -n npm/scripts/postinstall.test.js | sed -n '1,45p'
printf '%s\n' '--- repository Node-version declarations ---'
rg -n --hidden -g '!node_modules' -g '!dist' -g '!build' \
'(14\.0\.0|14\.14\.0|16\.17\.0|engines|setup-node|NODE_VERSION|node-version|\.nvmrc|\.node-version)' \
package.json .nvmrc .node-version 2>/dev/null || true
printf '%s\n' '--- relevant history-independent source references ---'
rg -n --glob '*.js' --glob '*.json' '(rmSync|node:test|--test)' npm package.jsonRepository: KubeOrch/cli
Length of output: 6354
🌐 Web query:
Node.js official documentation fs.rmSync added v14.14.0 node:test and --test added v16.17.0
💡 Result:
The fs.rmSync method in Node.js was introduced in version v14.14.0, which added the fs.rm and fs.rmSync methods to the fs module [1]. The node:test module and the --test command-line flag were introduced as experimental features in Node.js version v16.17.0 [2][3][4]. These features later reached stability in version v20.0.0 [2][5][4].
Citations:
- 1: nodejs/node@1610728d7c
- 2: https://nodejs.org/docs/v20.13.1/api/test.html
- 3: https://nodejs.org/download/release/v16.17.0/docs/api/test.html
- 4: https://nodejs.org/docs/latest-v24.x/api/test.html
- 5: https://nodejs.org/dist/latest/docs/api/test.html
Use APIs supported by the declared Node.js baseline.
The package declares "node": ">=14.0.0".
npm/scripts/postinstall.js#L201:fs.rmSyncrequires Node.js 14.14.0 or later. On Node.js 14.0.0, installation can fail.npm/scripts/postinstall.test.js#L6andpackage.json#L13:node:testandnode --testrequire Node.js 16.17.0 or later. Tests can fail before execution.
Use Node.js 14-compatible APIs, or raise the declared baseline to Node.js 16.17.0 or later and enforce it in CI.
📍 Affects 3 files
npm/scripts/postinstall.js#L201-L201(this comment)npm/scripts/postinstall.test.js#L6-L6package.json#L13-L13
Signed-off-by: Mohit Nagaraj <mohitnagaraj20@gmail.com>
1 participant
Summary
init -> start -d -> status -> browser-to-Core request -> stopwith bounded evidence and cleanupVerification
go test -count=1 ./...go vet ./...go test -race -count=1 ./...in Linux with Dockernpm testv0.0.8checksumsGET /v1/api/auth/methods => 200, no browser console errorsRelease gate
This PR intentionally references rather than closes #50. Candidate evidence can run now. Final published evidence remains blocked until compatible multi-architecture Core and UI releases exist, their digests replace the CLI's current
v0.0.3defaults, and the physical Apple Silicon run is attached. GitHub-hosted macOS ARM64 runners validate both installers but cannot run Docker because nested virtualization is unavailable.Refs #50
Refs #47