Skip to content

ci(cli): validate installed Eval frameworks - #3188

Merged
M4n5ter merged 3 commits into
mainfrom
ci/cli-eval-release-validation
Aug 18, 2026
Merged

ci(cli): validate installed Eval frameworks#3188
M4n5ter merged 3 commits into
mainfrom
ci/cli-eval-release-validation

Conversation

@M4n5ter

@M4n5ter M4n5ter commented Aug 18, 2026

Copy link
Copy Markdown
Member
English

Summary

Extend the immutable CLI tarball gate with cross-platform Eval spec and Python-framework preflight checks, plus one Ubuntu job that completes deterministic Harbor and Pier Docker cells without provider credentials.

The real Pier cell exposed that an explicit mount list replaced framework-owned log mounts. Preserve those mounts and inventory the Pier artifact layout so execution scope, verifier rewards, and collected subject output survive the installed-package path.

Refs #3166

Verification

  • npm run typecheck
  • npm run build
  • npm --workspace @maka/eval run test:dist
  • npm run check:release
  • node scripts/smoke-release-cli-package.mjs
  • npm run release:cli:eval with Harbor 0.20.0 and datacurve-pier 0.3.0 in separate Python 3.12 environments
  • actionlint v1.7.7 on cli-package-validation.yml
  • Biome lint and format on changed files

AI use

Select exactly one:

  • No generative tool made a substantive contribution
  • Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex implemented the release validation, diagnosed the Pier integration failure, added the root fix and tests, and ran verification. M4n5ter is the human contributor of record.

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — described under Summary above
  • No
中文

摘要

扩展同一份不可变 CLI tarball 的发布门禁:三平台验证 Eval spec 与 Python framework preflight,并增加一个 Ubuntu job,使用相互隔离的 Python 3.12 环境顺序完成无 provider 凭证的 Harbor 和 Pier 真实 Docker cell。

真实 Pier cell 暴露出显式 mounts 会替换 framework 自有日志挂载。现在适配层保留这些挂载,并按 Pier 的实际目录回收 artifacts,确保安装包路径下的执行作用域、verifier reward 和 subject 输出都能完整落盘。

关联 #3166。验证项与 AI 披露以英文区为准。

Run Harbor and Pier against the same immutable CLI tarball after cross-platform spec and prerequisite checks. Use deterministic local tasks so the release gate exercises the installed relay, Docker environment, verifier result, artifacts, and cleanup without provider credentials.

Preserve Pier's framework-owned log mounts when adding user mounts; otherwise an explicit empty mount list replaces the paths required for subject scope, rewards, and collected artifacts.

Generated-by: OpenAI Codex
@coderabbitai

coderabbitai Bot commented Aug 18, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@M4n5ter, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 4 minutes

Limit details: You’ve used all 3 included reviews currently available under your plan.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 63807c76-35c5-41d8-b380-18cdb491e2be

📥 Commits

Reviewing files that changed from the base of the PR and between 1845005 and 10a3849.

📒 Files selected for processing (1)
  • packages/eval/src/__tests__/lifecycle-boundaries.test.ts
📝 Walkthrough

Summary

This PR closes the immutable CLI tarball release-validation gap. It validates Eval specifications and Python framework environments before execution. It runs deterministic Harbor and Pier Docker cells against the installed tarball. It preserves Pier framework mounts, execution scope, verifier rewards, and collected artifacts.

The PR extends the existing release and smoke-validation paths. It adds one standalone Eval release-validation script and one CI job. It does not replace the production execution system or add public exports.

The solution is the smallest coherent approach shown by the current diff. The added script is necessary for offline installation, deterministic fixtures, timeout handling, credential sanitization, framework-output checks, artifact checks, and cleanup. No deletion or simplification is evident without weakening framework-specific regression coverage.

Complexity delta

  • Authorities: Adds framework-specific artifact roots and reserved Pier mount paths. Existing Harbor mount behavior remains unchanged.
  • State: Adds isolated install prefixes, temporary Git fixtures, Docker cells, framework outputs, attempt files, diagnostics, and cleanup tracking.
  • Branches: Adds Harbor/Pier selection, Python preflight handling, mount reservation, framework-output parsing, and diagnostic-error handling.
  • Configuration: Adds release:cli:eval, pinned Harbor 0.20.0 and DataCurve Pier 0.3.0 environments, Python path exports, and a CI eval job.
  • Public surface: Adds no exported or public entities.
  • Test maintenance: Adds lifecycle, support, preflight, and deterministic release-validation coverage. It increases maintenance for the standalone fixture and pinned framework versions.

The total maintenance complexity increases. The increase is justified by the broader immutable-tarball release gate. No safe deletion is evident from the current diff.

Validation

The PR includes:

  • Typecheck and build checks.
  • Distribution, release, and CLI package smoke checks.
  • Cross-platform Eval specification validation.
  • Harbor and Pier Python preflight checks.
  • Deterministic Harbor and Pier Docker validation.
  • Output, attempt, artifact, score, diagnostic, and cleanup assertions.
  • Pier mount-reservation and artifact-layout regression tests.
  • actionlint and Biome verification.

The final status of required checks is unverified because direct check results are not provided.

Review-relevant risks

  • The workflow validates an immutable release tarball with Docker and pinned external Python frameworks. This affects release governance and release confidence. Material release-process changes require independent human review under repository policy.
  • The release scripts create fixtures, execute generated commands, sanitize credentials, and process framework diagnostics. This affects security-sensitive validation behavior. Material security changes require independent human review under repository policy.
  • harness-executor.ts changes Pier mounts, verification inputs, artifact inventory, and retained outputs. This can affect user-visible Eval behavior and artifact contracts. Material behavior or contract changes require independent human review under repository policy.
  • The workflow adds Node 24, Python 3.12, Harbor 0.20.0, and DataCurve Pier 0.3.0 as release-validation dependencies. This affects supported release environments and dependency governance. Material dependency or licensing changes require independent human review under repository policy.

The person performing the merge must review the final diff. A maintainer makes the final determination.

Walkthrough

Changes

Eval release validation

Layer / File(s) Summary
Framework-specific runtime handling
packages/eval/src/harness-executor.ts, packages/eval/src/__tests__/lifecycle-boundaries.test.ts
Verification and environment configuration now receive framework context. Pier uses direct artifact discovery and receives agent, verifier, and artifact mounts. Lifecycle tests cover reserved mounts, configured mounts, and framework environment isolation.
Release validation support
scripts/release-cli-eval-support.mjs, scripts/release-cli-eval-support.test.mjs
Adds isolated environments, deterministic Git task fixtures, bounded command execution, framework output parsing, diagnostic collection, and structured failure reporting. Tests cover platform checks, fixture isolation, preserved primary failures, and malformed output.
CLI Eval release validator
scripts/release-cli-eval-package.mjs
The release validator verifies one Linux x64 CLI tarball, installs it offline, runs deterministic Harbor and Pier Eval cells, checks outputs and artifacts, and verifies container cleanup.
Installed CLI Eval preflight
scripts/smoke-release-cli-package.mjs
Installed-product smoke validation runs Harbor and Pier preflight commands and checks the expected unavailable-Python errors.
Release validation CI wiring
package.json, .github/workflows/cli-package-validation.yml
Adds the release:cli:eval command and a CI job with pinned Harbor and Pier environments.

Estimated code review effort: 4 (Complex) | ~45 minutes

Merge Risk: 🔵 Low · up to 18450

The release gate now validates installed Eval frameworks and Docker cells, but floating runtime and transitive dependency resolution can make results vary for identical CLI artifacts; merge is reasonable with explicit owner awareness or follow-up to pin or constrain those inputs.

Sequence Diagram(s)

sequenceDiagram
  participant CI
  participant ReleaseValidator
  participant EvalCLI
  participant Harbor
  participant Pier
  participant Docker
  CI->>ReleaseValidator: run release:cli:eval
  ReleaseValidator->>EvalCLI: install and invoke CLI
  EvalCLI->>Harbor: execute Eval cell
  EvalCLI->>Pier: execute Eval cell
  Harbor->>Docker: run trial containers
  Pier->>Docker: run trial containers
  ReleaseValidator->>EvalCLI: inspect results and artifacts
  ReleaseValidator->>Docker: verify cleanup
Loading

Possibly related PRs

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely describes the main change: CI validation for the installed CLI Eval frameworks.
Description check ✅ Passed The description follows the template and includes the summary, issue reference, verification commands, AI disclosure, checklist, and behavior change.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Ai Use Disclosure ✅ Passed The PR selects substantive generative-tool use, names OpenAI Codex and its scope, and both introduced commits contain the consistent trailer Generated-by: OpenAI Codex.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch ci/cli-eval-release-validation

Comment @coderabbitai help to get the list of available commands.

@M4n5ter
M4n5ter marked this pull request as ready for review August 18, 2026 04:59
@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Validate installed CLI with Harbor and Pier Eval frameworks

✨ Enhancement 🐞 Bug fix 🧪 Tests ⚙️ Configuration changes 🕐 40+ Minutes

Grey Divider

AI Description

• Adds cross-platform installed-package Eval spec and framework preflight validation.
• Runs credential-free Harbor and Pier Docker cells against the immutable CLI tarball.
• Preserves Pier log mounts and collects artifacts from its native trial layout.
Diagram

sequenceDiagram
  participant B as Build job
  participant A as CLI artifact
  participant S as Platform smoke
  participant E as Eval gate
  participant C as Installed CLI
  participant F as Harbor and Pier
  participant D as Docker
  participant R as Attempt results
  B->>A: Publish tarball
  A->>S: Install candidate
  S->>C: Decode specs and preflight
  A->>E: Download candidate
  E->>C: Offline install
  loop Each framework
    C->>F: Run deterministic cell
    F->>D: Build and execute
    D-->>F: Return reward and logs
    F-->>R: Collect artifacts
  end
  E->>D: Verify cleanup
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Separate framework matrix jobs
  • ➕ Runs Harbor and Pier in parallel
  • ➕ Provides isolated framework logs and failure status
  • ➕ Allows independent framework timeouts and retries
  • ➖ Duplicates Node, Python, artifact, and installation setup
  • ➖ Uses more CI capacity
  • ➖ Weakens the single-job sequential validation scenario
2. Embed Docker cells in platform smoke
  • ➕ Keeps release validation in one script
  • ➕ Reuses existing installation and checksum setup
  • ➖ Real framework cells only support Linux x64
  • ➖ Would complicate cross-platform smoke behavior
  • ➖ Makes fast packaging checks depend on Docker and Python frameworks

Recommendation: Keep the layered approach: cross-platform smoke checks should validate installed spec decoding and prerequisite errors, while the dedicated Ubuntu gate should run positive Harbor and Pier Docker cells. A framework matrix could improve failure isolation later, but the current sequential job minimizes duplicated setup and still validates both frameworks against the same immutable artifact.

Files changed (6) +585 / -12

Bug fix (1) +31 / -7
harness-executor.tsPreserve Pier mounts and native artifact paths +31/-7

Preserve Pier mounts and native artifact paths

• Appends Pier-owned agent, verifier, and artifact log mounts instead of replacing them with configured mounts. Artifact inventory now selects the framework-specific layout so Pier outputs and rewards remain discoverable.

packages/eval/src/harness-executor.ts

Tests (3) +520 / -5
lifecycle-boundaries.test.tsVerify Pier preserves framework log mounts +45/-5

Verify Pier preserves framework log mounts

• Converts the lifecycle boundary scenario to Pier and supplies an explicit user mount. It asserts that the launched environment excludes the framework selector while retaining user, agent, verifier, and artifact mounts.

packages/eval/src/tests/lifecycle-boundaries.test.ts

release-cli-eval-package.mjsValidate real Eval cells from the release tarball +400/-0

Validate real Eval cells from the release tarball

• Adds a Linux x64 release validator that verifies the tarball checksum, installs it offline, and runs deterministic Harbor and Pier Docker cells with pinned Python environments. It checks completed attempts, rewards, collected artifacts, diagnostics, container cleanup, and temporary-file cleanup without provider credentials.

scripts/release-cli-eval-package.mjs

smoke-release-cli-package.mjsSmoke-test installed Eval decoding and preflight +75/-0

Smoke-test installed Eval decoding and preflight

• Extends installed-package smoke validation with Harbor and Pier experiment specs. Each check confirms the packaged CLI decodes the framework configuration and rejects an invalid Python executable during preflight before task execution.

scripts/smoke-release-cli-package.mjs

Other (2) +34 / -0
cli-package-validation.ymlAdd installed CLI Eval integration gate +33/-0

Add installed CLI Eval integration gate

• Adds an Ubuntu job that downloads the built CLI candidate, provisions isolated pinned Harbor and Pier Python environments, and runs real Docker cells. The job validates the same immutable artifact produced by the build stage.

.github/workflows/cli-package-validation.yml

package.jsonExpose the CLI Eval release validation command +1/-0

Expose the CLI Eval release validation command

• Adds the 'release:cli:eval' npm script for invoking the installed-package Harbor and Pier validation.

package.json

@qodo-code-review

qodo-code-review Bot commented Aug 18, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Action required

1. Duplicate Pier mount targets ✓ Resolved 🐞 Bug ≡ Correctness
Description
Pier now appends framework mounts for /logs/agent, /logs/verifier, and /logs/artifacts without
rejecting configured mounts using those same targets. Existing valid specs—including likely
workarounds for the prior lost-log-mount behavior—can therefore reach Docker with duplicate
destinations and fail before the trial starts.
Code

packages/eval/src/harness-executor.ts[R1002-1005]

+          ...configuredMounts,
+          { type: 'bind', source: join(trialPath, 'agent'), target: '/logs/agent' },
+          { type: 'bind', source: join(trialPath, 'verifier'), target: '/logs/verifier' },
+          { type: 'bind', source: join(trialPath, 'artifacts'), target: '/logs/artifacts' },
Relevance

●●● Strong

Accepted bug finding matches recent team precedent for preventing framework/container mount
conflicts; configured targets can duplicate appended Pier mounts.

PR-#2674
PR-#3169

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Mount decoding currently accepts any absolute target, including the three /logs/* destinations,
while the changed Pier branch unconditionally appends mounts with those destinations. Docker’s mount
registration rejects a HostConfig.Mounts destination already present in the bind destination set
with duplicateMountPointError, so such a Pier configuration cannot create its container.

packages/eval/src/harness-executor.ts[966-975]
packages/eval/src/harness-executor.ts[998-1007]
🌐 Moby rejects a HostConfig mount when its destination duplicates an already registered bind destination.

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Pier appends three framework-owned mounts after all configured mounts, but configured mounts may already target the same paths. Reject these collisions during existing executor configuration validation so failures are actionable and occur before Docker startup.

## Issue Context
Reuse the existing mount decoding/validation seam; no new configuration, state, or public surface is needed. Add regression coverage for a Pier mount targeting a framework-owned log path.

## Fix Focus Areas
- packages/eval/src/harness-executor.ts[966-975]
- packages/eval/src/harness-executor.ts[998-1007]
- packages/eval/src/__tests__/lifecycle-boundaries.test.ts[1354-1375]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context
✅ Web pages:
  +14 more
Review mode: ⚖️ Balanced: Downgraded extended -> standard: change is below the extended eligibility bar (hunks 15/18, lines 597/200; both must reach the floor). Router rationale: This is a behavior-changing CI and Eval integration PR with substantial new release-validation logic across multiple independent paths, plus framework-specific mount/artifact changes where several subtle defects could evade a single pass.

Grey Divider

Tip of the day
💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread packages/eval/src/harness-executor.ts Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🧹 Nitpick comments (1)
scripts/release-cli-eval-package.mjs (1)

249-264: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Use the isolated environment for the fixture git commands (disposition: follow-up).

These git calls pass process.env. The host HOME stays in scope, so user or system git configuration applies. Settings such as commit.gpgsign, core.hooksPath, or init.templateDir can make the commit fail or add unexpected files, which breaks the determinism this fixture provides. isolatedEnvironment already produces a clean HOME; reuse it here instead of adding new configuration flags.

Source: Path instructions


ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 17eb6f79-3d4d-4fe0-befe-0b91d7e72ab3

📥 Commits

Reviewing files that changed from the base of the PR and between 32e3cbb and 974e8c6.

📒 Files selected for processing (6)
  • .github/workflows/cli-package-validation.yml
  • package.json
  • packages/eval/src/__tests__/lifecycle-boundaries.test.ts
  • packages/eval/src/harness-executor.ts
  • scripts/release-cli-eval-package.mjs
  • scripts/smoke-release-cli-package.mjs

Included review availability: Your plan includes up to 3 reviews per rolling hour; 0 remain after this review.

Comment thread .github/workflows/cli-package-validation.yml
Comment thread scripts/release-cli-eval-package.mjs Outdated
Comment thread scripts/release-cli-eval-package.mjs Outdated
Comment thread scripts/release-cli-eval-package.mjs Outdated
Reserve Pier's framework-owned log subtrees before Docker composition so configured mounts cannot shadow verifier rewards or collected artifacts. Keep framework failures authoritative when summary or diagnostic evidence is malformed or unreadable, and create the deterministic Git fixture under the same isolated environment as the installed candidate.

Generated-by: OpenAI Codex

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
packages/eval/src/__tests__/lifecycle-boundaries.test.ts (1)

1377-1403: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Retain the Harbor regression case alongside the Pier case. The current test only exercises createPierExecutor and asserts Pier’s log mounts and framework environment. The remaining Harbor tests do not cover these Harbor-specific assertions.

Source: Path instructions


ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ac6429d6-2bf5-46c4-8822-99278eafe4b6

📥 Commits

Reviewing files that changed from the base of the PR and between 974e8c6 and 1845005.

📒 Files selected for processing (6)
  • package.json
  • packages/eval/src/__tests__/lifecycle-boundaries.test.ts
  • packages/eval/src/harness-executor.ts
  • scripts/release-cli-eval-package.mjs
  • scripts/release-cli-eval-support.mjs
  • scripts/release-cli-eval-support.test.mjs
🚧 Files skipped from review as they are similar to previous changes (1)
  • package.json

Included review availability: Your plan includes up to 3 reviews per rolling hour; 0 remain after this review.

Comment thread packages/eval/src/__tests__/lifecycle-boundaries.test.ts Outdated
Use an exact predicate for the observable Pier mount rejection so path punctuation cannot weaken the regression check.
@M4n5ter

M4n5ter commented Aug 18, 2026

Copy link
Copy Markdown
Member Author

The current PR changes have been manually reviewed by me. I take responsibility for this result and decide to merge them.

@M4n5ter
M4n5ter merged commit 62f550c into main Aug 18, 2026
20 checks passed
@M4n5ter
M4n5ter deleted the ci/cli-eval-release-validation branch August 18, 2026 06:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant