Alpha gate A: OwnSharp.Cli — the single ownsharp check command#210
Conversation
…202) Implements the packaging decision recorded in issue #202: one dotnet global tool (`OwnSharp.Cli`, command `ownsharp`) that wraps the existing extractor -> core pipeline into one install, exactly mirroring what scripts/own-check.sh already does by hand. - The Roslyn extractor (OwnSharp.Extractor) is pulled in via ProjectReference, unmodified; `check` invokes its bundled dll as a child process (`dotnet exec`), the same subprocess shape own-check.sh already uses. - The Python core (ownlang/) is vendored as loose *.py content, unmodified, and unpacked to ~/.ownsharp/core/<version>/ on first run -- never into the analyzed repo. It runs on the machine's own Python (OWN_PYTHON env var, else `py -3`/`python3`, >=3.11), with a fast, actionable, one-line failure (winget/apt/brew per OS) and no auto-download if none is found. - CLI flags mirror own-check.sh 1:1 (--format, --severity, --fail-on-finding, --emit-facts, --legacy, --stats, --body-throw-edges); the exit-code contract (0/1/>=2, plus 3 for "no Python") is unchanged from the scripts. No behaviour changes to the extractor or core -- packaging only, per the issue's guardrail. own-check.sh/.ps1 and action.yml are untouched. CI: a new ownsharp-cli-smoke job (matrix: ubuntu-latest + windows-latest) proves pack -> dotnet tool install --global -> ownsharp check finds a real leak on a clean runner, gated on a regression-ceiling timer, plus a separate assertion that the no-Python path fails fast with the actionable message. Docs: frontend/roslyn/OwnSharp.Cli/README.md (the tool itself), updates to alpha-readiness.md gate A, P-013's Scope, and the root README's local-quickstart paragraph -- all noting honestly that the package isn't published to nuget.org yet (build-and-install from source until then).
|
Warning Review limit reached
Next review available in: 10 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (13)
✨ Finishing Touches🧪 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 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ee6583a1d8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| private static async Task<int> RunExtractorAsync( | ||
| IReadOnlyList<string> paths, string factsPath, bool legacy, bool stats, bool bodyThrowEdges) | ||
| { | ||
| var extractorDll = Path.Combine(AppContext.BaseDirectory, "OwnSharp.Extractor.dll"); |
There was a problem hiding this comment.
Use the actual extractor assembly name
When ownsharp check runs after a tool install, this path is checked before extraction, but the referenced extractor project sets <AssemblyName>ownsharp-extract</AssemblyName> in frontend/roslyn/OwnSharp.Extractor/OwnSharp.Extractor.csproj, so the build/pack output is ownsharp-extract.dll, not OwnSharp.Extractor.dll. As a result every normal check invocation reports the bundled extractor as missing and exits before producing facts/findings.
Useful? React with 👍 / 👎.
…actor.dll OwnSharp.Extractor.csproj sets <AssemblyName>ownsharp-extract</AssemblyName>, so the built/packed DLL is ownsharp-extract.dll — the project/package name is not the assembly name. CheckCommand.RunExtractorAsync was checking for the wrong filename, so every check invocation reported a corrupt install and exited before producing findings. Also fixed the two cosmetic comment references (csproj, README) to match. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D6Naf8CcezjCbikueKdeYv
Что и зачем
Реализует пакетное решение, записанное в #202 (комментарий с архитектурным решением): один
dotnet tool(OwnSharp.Cli, командаownsharp) оборачивает существующий пайплайн extractor → core в одну установку —ownsharp check <path|.sln>. Никаких изменений в поведении экстрактора или ядра, только упаковка.Тип изменения
Как проверено
python tests/run_tests.pyruff check .иmypypython scripts/<...>.py --selftest)Локальных
dotnet/C#-тулчейнов в песочнице нет (как и для остального C#-кода в этом репо) — питоновская часть не тронута,python tests/run_tests.py/ruff/mypyпрогнаны и зелёные (ничего не сломано). Новый C#-код проверяется исключительно через CI: новая джобаownsharp-cli-smoke(matrix ubuntu-latest + windows-latest) реально паковает, ставитdotnet tool install --global, запускаетownsharp checkна реальном лике и проверяет no-Python fail-fast путь.Связанные issue
Closes #202.
Чеклист
ownsharp-cli-smokefeat:,fix:,docs:…)Пакетная форма (решение из #202, не пересматривается)
ProjectReference;checkзапускает его как дочерний процесс (dotnet exec <bundled>/OwnSharp.Extractor.dll ...), тем же способом, каким это уже делаетscripts/own-check.sh.*.py(zero-dependency,pyproject.toml: requires-python >=3.11), распаковывается в~/.ownsharp/core/<version>/при первом запуске, никогда — в анализируемый репозиторий. Выполняется системным Python.OWN_PYTHON→ иначеpy -3(Windows) /python3(остальные), версия проверяется (>=3.11); если не найден — быстрый отказ с однострочной инструкцией (winget/apt/brew/python.org), без автоскачивания. (Плюс мягкий фолбэк наpython3/pythonпослеpy -3на Windows — не ослабляет контракт "версия ≥3.11 или отказ", просто снижает ложные "не найдено" на реальных машинах.)scripts/own-check.sh1:1:--format,--severity,--fail-on-finding,--emit-facts,--legacy,--stats,--body-throw-edges. Контракт кодов возврата тот же (0 чисто / 1 находки / ≥2 hard error), плюс3— не найден Python.ownsharp check <path|.sln>CLI — implementation (design decided, see comments) #202 (встраивание CPython, PyInstaller как дефолт, ждать Rust, порт на C#) — не пересматривались.CI-доказательство (issue's acceptance)
Новая джоба
ownsharp-cli-smoke(.github/workflows/ci.yml), matrixubuntu-latest+windows-latest— специально оба, а не "для покрытия":dotnet tool-шим на Windows — нативный apphost, на Unix — shell-скрипт, разная механика запуска процесса. Шаги: pack →dotnet tool install --global→ownsharp checkна минимальном лике в scratch-директории ВНЕ репозитория (доказывает, что тулу не нужен чекаут репо) → таймер install→check→findings с щедрым потолком регрессии (240s, не точное число "~3 минуты", а страховка от "стало занимать 20 минут") → отдельная проверка no-Python-пути (OWN_PYTHONна несуществующий путь) на exit 3 + текст с actionable-инструкцией.Честно: не опубликовано в nuget.org
Публикация в nuget.org явно вне скоупа (P-013 Non-goals, не менялось). Сегодня — сборка и установка из исходников (
frontend/roslyn/OwnSharp.Cli/README.md).alpha-readiness.mdgate A обновлён честно: "построено", а не "опубликовано".Generated by Claude Code