State the Pythons CI tests, and read them rather than typing them - #1
Conversation
The readiness block said "Python 3.11 and later" as a literal. It now says "Python 3.11 and later, tested on 3.11 to 3.14", with the floor read from the library's requires-python and the tested list from its CI check matrix, so adding or dropping a version there drifts this block until it is regenerated. A floor CI does not test is refused. The install page says which Pythons CI runs the suite on. Only the new python field was added to generated/readiness.json; the recorded test count is unchanged.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
|
Warning Review limit reachedNext included review available in 24 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: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (3)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe readiness audit now reads the Python requirement and tested CI versions from project configuration. It generates the Python support sentence, checks documentation drift, and updates three documentation pages to state testing on Python 3.11 through 3.14. ChangesPython support documentation
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This PR only changes how Python support documentation is generated and displayed, deriving the supported version range from project configuration and CI instead of hardcoding it. No unresolved functional or dependency issues were found in review, so this change is low risk and ready to merge. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 57.14% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 7 functions across 1 files. (3 skipped: 3 unsupported.) ✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 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 |
The conflicts were all in generated files, so they are resolved by running the generators rather than by hand-merging two renders. The Python line this branch adds survives it: 'Python 3.11 and later, tested on 3.11 to 3.14'. T180 still fails here for a reason that belongs to main, not to this branch: the DCO entry CTRLRun/ctrlrun#169 added to the kernel's CHANGELOG trips the signature scan. PR #13 allow-lists it. Signed-off-by: arpan <arpanghoshalwork@gmail.com>
… branch's generator The two pages and the four generated files conflicted on the test count and the version; the branch's generator was kept and everything it renders was regenerated against the kernel's main, then pasted fresh into the two pages that carry the block. Signed-off-by: arpan <contact@arpanghoshal.com>
…ease branch Main brought #1 (the Pythons CI tests, read rather than typed), #18 (the assurance case) and #21 (the README test and the badge generator). The readiness block conflicted on both sides' regenerations; regenerated once more against the kernel's release/0.10.0 and pasted fresh. Signed-off-by: arpan <contact@arpanghoshal.com>
`main` has been red since #18, #1 and #21 landed: three push runs failed in a row, all on `docs/security/assurance-case.mdx`. Every branch cut afterwards inherits it, this one included, so the release cannot go green without fixing it. Four are the page's, one is the list's. - **The description was 198 characters**, and the limit is 155 because that is where a search result truncates. Rewritten to say the same thing in one sentence. - **No `## Next`**, which every `.mdx` carries so a reader is never left at the bottom of a page with nowhere to go. Added, with four links. - **No link to Why and none to Get started.** Both are in that section now. - **`SEO.md` had no row.** The file is the plan, one row per page; a page with no row is a page nobody decided what it was for. Query and definitional sentence added beside the other `docs/security/` rows. - **1,816 words against a 900 budget.** `security/assurance-case` joins `LONG_FORM`, where `THREAT_MODEL`, `ARCHITECTURE`, `CLAIMS` and the OWASP pages already are. Cutting an assurance case to 900 words means dropping either a claim or the evidence under one, and a claim without its evidence is what the page exists to refuse. The reason is in the list beside the entry. Readiness regenerated after the merge: **6,066** tests, pasted into both homes.
What
Python 3.11 and later.becomesPython 3.11 and later, tested on 3.11 to 3.14.render_readiness.pyno longer types the Python sentence. It reads the floor from the library'srequires-pythonand the tested list from the library's CIcheckmatrix, and--checkcompares both, so a version added to or dropped from that matrix drifts this block until it is regenerated. It refuses a floor CI does not test, a non->=3.Nrequires-python, and an unquoted matrix entry (YAML reads3.10as the float3.1).generated/readiness.jsongains only thepythonfield. The recorded test count is unchanged:--writere-counts with whatever is installed locally, and a count taken with the adapter frameworks installed would exceed what CI collects and fail the floor check.Depends on CTRLRun/ctrlrun#134
This PR's CI reads the library's
main. Until #134 (which adds 3.13 and 3.14 to the matrix) is merged,render_readiness.py --checkhere reportspython changed since the block was generated, which is the check doing its job. Re-run CI after #134 merges.Checked locally, against the #134 branch
scripts/check.sh: ruff format, ruff check, 1566 passedlint.py,links.py, and all ninerender_*.py --check: 0 driftdocs/production/index.mdxmakesrender_readiness.py --checkreportreadiness block differs.🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
Maintenance