Skip to content

test(coverage): simulate Linux x86_64 in trusted-uv installer tests - #960

Draft
seonghobae wants to merge 4 commits into
mainfrom
test/trusted-uv-installer-platform-mock
Draft

test(coverage): simulate Linux x86_64 in trusted-uv installer tests#960
seonghobae wants to merge 4 commits into
mainfrom
test/trusted-uv-installer-platform-mock

Conversation

@seonghobae

Copy link
Copy Markdown
Contributor

Summary

Five installer verification tests called _install_trusted_uv() without pinning the runner. On macOS they raised supports only linux x86_64 runners before version, cache, or cleanup coverage ran, so the local full suite could not reach 100%.

  • _simulate_linux_x86_64_runner() pins sys.platform and platform.machine() only in those unit tests.
  • Production still fail-closes unsupported runners before download (existing portability contract).

Test plan

  • pytest tests/test_materialize_base_python_requirements.py tests/test_trusted_uv_portability_and_streaming.py — 42 passed
  • pytest tests — 977 passed, 100% statements/branches, interrogate 100%
  • Current-head required checks on this PR

Installer verification, cache, and cleanup coverage was unreachable on
macOS because the production gate rejects non-Linux runners first.
Pin platform and machine only in those unit tests; the portability
contract still fail-closes unsupported hosts before any download.
@seonghobae
seonghobae enabled auto-merge (squash) August 13, 2026 06:41
@seonghobae

Copy link
Copy Markdown
Contributor Author

@cwl-noema-review please review this current head. Installer verification tests now pin linux/x86_64 so local full-suite coverage is 100%; production still fail-closes unsupported runners.

@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown

Warning

Review limit reached

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

Next review available in: 109 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

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: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e2304c63-13ce-472d-a0d6-bb280c3bee50

📥 Commits

Reviewing files that changed from the base of the PR and between 6eb06cd and 1d8e620.

📒 Files selected for processing (8)
  • AGENTS.md
  • ARCHITECTURE.md
  • CHANGELOG.md
  • CLAUDE.md
  • docs/doctoring/trusted-uv-lock-materialization.md
  • scripts/ci/materialize_base_python_requirements.py
  • tests/test_materialize_base_python_requirements.py
  • tests/test_trusted_uv_portability_and_streaming.py

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.

❤️ Share

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

Clear the process-cached installer after the Linux x86_64 monkeypatch
so version verification is measured on the simulated runner, not a
stale host-architecture miss.
Debian-style runners report amd64 or AMD64 for the same userspace the
pinned uv-x86_64-unknown-linux-gnu archive targets. Normalize the
machine label and fail-closed only for a different ISA.
Materialize a base Python lock only when every package line is an exact
SHA-256 pin or a two-token relative -r/--requirement include of a
candidate lock path. A lone --require-hashes directive, ./dotted paths,
and -r other-hashes.txt no longer enter the trusted build context.

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

OpenCode could not approve from deterministic current-head evidence because GitHub Checks have failed.

Findings

1. HIGH Current-head GitHub Checks - Fix failed required checks before approval

  • Problem: Failed same-head checks remain for 1d8e6208e575540ec2f0819be39bd711dc902905.
  • Root cause: The model-unavailable evidence fallback is allowed only when peer GitHub Checks are complete and clean.
  • Fix: Read and fix the failed check logs below, then rerun the current-head checks.
  • Regression test: Keep the model-unavailable fallback gated on an empty failed-check rollup.

Failed checks:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (4 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (4 files)"]
  R1 --> V1["required checks"]
  Evidence --> S2["Docs: trusted-uv-lock-materialization.md"]
  S2 --> I2["operator or user guidance"]
  I2 --> R2["Review risk: Docs: trusted-uv-lock-materialization.md"]
  R2 --> V2["docs review"]
  Evidence --> S3["CI script: materialize_base_python_requirements.py"]
  S3 --> I3["review and security gate shell path"]
  I3 --> R3["Review risk: CI script: materialize_base_python_requirements.py"]
  R3 --> V3["bash -n plus Strix self-test"]
  Evidence --> S4["Test (2 files)"]
  S4 --> I4["regression suite"]
  I4 --> R4["Review risk: Test (2 files)"]
  R4 --> V4["targeted test run"]
Loading

@opencode-agent

Copy link
Copy Markdown
Contributor

OpenCode Review Overview

  • Head SHA: 1d8e6208e575540ec2f0819be39bd711dc902905
  • Workflow run: 31754633591
  • Workflow attempt: 1
  • Gate result: REQUEST_CHANGES (approval step)

Pull request overview

OpenCode could not approve from deterministic current-head evidence because GitHub Checks have failed.

Findings

1. HIGH Current-head GitHub Checks - Fix failed required checks before approval

  • Problem: Failed same-head checks remain for 1d8e6208e575540ec2f0819be39bd711dc902905.
  • Root cause: The model-unavailable evidence fallback is allowed only when peer GitHub Checks are complete and clean.
  • Fix: Read and fix the failed check logs below, then rerun the current-head checks.
  • Regression test: Keep the model-unavailable fallback gated on an empty failed-check rollup.

Failed checks:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (4 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (4 files)"]
  R1 --> V1["required checks"]
  Evidence --> S2["Docs: trusted-uv-lock-materialization.md"]
  S2 --> I2["operator or user guidance"]
  I2 --> R2["Review risk: Docs: trusted-uv-lock-materialization.md"]
  R2 --> V2["docs review"]
  Evidence --> S3["CI script: materialize_base_python_requirements.py"]
  S3 --> I3["review and security gate shell path"]
  I3 --> R3["Review risk: CI script: materialize_base_python_requirements.py"]
  R3 --> V3["bash -n plus Strix self-test"]
  Evidence --> S4["Test (2 files)"]
  S4 --> I4["regression suite"]
  I4 --> R4["Review risk: Test (2 files)"]
  R4 --> V4["targeted test run"]
Loading

@opencode-agent
opencode-agent Bot disabled auto-merge August 14, 2026 01:55
@seonghobae
seonghobae marked this pull request as draft August 14, 2026 09:12

Copy link
Copy Markdown
Contributor Author

Returned to Draft because this test-only portability slice carries production materializer and governance changes beyond its stated scope.

The useful change should be limited to a test helper that simulates Linux x86_64 only inside the installer verification cases, while preserving production fail-closed behavior on unsupported runners. Head 1d8e6208e575540ec2f0819be39bd711dc902905 also changes materialize_base_python_requirements.py, broad governance files, doctoring, and changelog.

After the authoritative materializer branch lands, rebuild this as a minimal test-only follow-up against protected main, retaining only the affected test modules and any strictly attributable test-contract note. Reconfirm that the helper cannot leak platform monkeypatches across tests, then reacquire exact-head coverage/security/supply-chain and independent-review evidence.

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