Checks on every pull request, and facts read from the repository

On repowise.dev, the PR bot now reports what the tests, the security scan and the docs say about a change, in a comment of its own. The open-source release, 0.54.0, spends most of its effort on getting the underlying facts right, and brings the same checks to any CI.

The Repowise checks comment

On repowise.dev.

Next to its review, the bot posts a second comment called Repowise checks. It is a short table, one row per check, and it is on by default.

• Tests lists which tests reach each changed file through the call graph or the import graph of the last indexed commit. It needs no setup. It is marked as inferred and never shows a percentage, because a test that reaches a file may not run the changed lines. On a recent pull request to repowise itself the row read "15 of 17 changed files reached by a test (inferred) · 1 reached by no test".
• Coverage is measured: the share of the changed lines the tests ran, with the uncovered ranges per file. It appears once your CI uploads a coverage report, either with one upload step in an existing workflow or through a draft pull request the bot opens for you that adds the workflow. The setup pull request detects Python, Node, Go and Java projects at the repository root.
• Security lists the findings on the lines the pull request adds, with secrets masked.
• Doc drift lists the docs the pull request edits that make a claim the code refutes.

Doc drift and the "run these tests first" line move out of the review comment while the checks comment is on, so nothing is said twice. By default the comment appears only when a check has something to say, and once posted it is updated to an all-clear line when the findings are gone.

Each row can be switched off, and each check can post its own GitHub check run that branch protection can require: Repowise / coverage below a minimum you set, Repowise / security at or above a severity, and Repowise / doc drift on a refuted claim. All three are off until you turn them on. Configure them under CI checks in PR Bot settings, or in .repowise/bot.yaml.

Do next on the overview

On repowise.dev and in the CLI.

The repository overview now opens on Do next: a short list of actions built from what the index already holds (health, performance, security, doc drift, dead code, decisions and coverage). Each action carries its reason, the effort it takes and what done looks like, split into this week and this quarter. On repowise-dev/repowise today it lists 2 actions for the week and 7 for the quarter, led by 45 serious findings in 35 files that this week's commits left behind.

On repowise.dev the list is read-only for now. Locally, repowise next prints the same list, and dismiss, snooze and done are remembered.

Coverage, drift and security gates in any CI

0.54.0 brings the same three checks to CI pipelines that do not use the bot.

repowise coverage check reports a change's patch coverage and fails below --fail-under. It needs git and a coverage report, with no index and no API key. --max-drop fails a change that lowers project coverage against the base, each uncovered range names up to three tests to extend, and the last 50 coverage ingests form a trend in the dashboard and in get_health.

repowise impacted-tests picks the tests a change needs and prints them as runner arguments for pytest, Go, Jest or Vitest. Anything it cannot be sure of runs the whole suite: lockfiles, build and CI config, changed files no test reaches, or an index built at neither end of the change.

repowise security check fails a change on the findings it adds, and repowise doc-drift now catches backticked names that were renamed or deleted, with the new name as the suggested fix when the history makes it clear. One GitHub Action and one GitLab template run all three gates in a single step, and a new CI guide covers them.

Facts read from the repository

Several rules used to guess where the repository could answer directly. They now read it.

• Entry points come from the manifest first. package.json bin, main, module and exports, [project.scripts] and package __init__.py files rank ahead of filename guesses, and test files are exempt from dead code through their own flag instead of being called entry points.
• A file keeps its history across renames. Churn, age, authorship, co-change partners and prior fixes follow the file to its new path.
• One person counts once. GitHub noreply addresses, handles and machine-local emails are merged into one contributor, bots are left out of people counts, and two real addresses are never joined on a shared name alone.
• "Commits" means non-merge commits everywhere, and history windows are measured from the indexed commit, so re-indexing an unchanged tree on a later day gives the same scores.
• Dead code stops flagging files a tool loads by name: *.config.*, .<tool>rc, .pnpmfile.cjs and sitecustomize.py.
• Python imports resolve by their full dotted path, so from pydantic import X can no longer land on a repository's own utils/pydantic.py.

Also in this release

• get_why answers from rationale comments and commit subjects when no decision record matches, labelled as such.
• Decisions whose commits were reverted are retired, and decisions whose files are all gone read as stale.
• Docs, config, workflows and data files carry commit history.
• Search ranks same-named symbols by case, then kind, then code before tests, and a name that does not exist returns no symbol.
• The C4 System Context view lists runtime services in place of every library, and test and example projects are no longer drawn as containers.
• On repowise.dev, Full AI review posts each point as a review thread on the line it is about, and Owners shows 90-day activity from the commit log with each person merged into one row.
• On repowise.dev, a failed payment has a 7-day grace period, and Pro can be cancelled in the app.
• The docs pages can be read as Markdown and copied in one click, and a new page says how repowise.dev handles your data.

Upgrading

pip install --upgrade repowise

Nothing needs re-indexing. The health analyzer version moved from 31 to 36, so the first update re-scores the repository once, and the parse cache refreshes on its own.