feat(review): enhance ignored files configuration and add tests for default patterns - #429
Merged
devops-thiago merged 1 commit intoJul 27, 2026
Conversation
🤖 ThrillhouseBot PR SummaryWhat this PR doesExpands the default set of file patterns that are skipped during pull-request review to cover lockfiles, build directories, minified/generated code, and vendor/output dirs across common ecosystems, and adds tests verifying the new defaults. Changes Overview
Changed Files
Risk Assessment
No new issues found in this PR, but the review cannot be approved until required CI is confirmed green.
|
| Check | Type | Status | Detail |
|---|---|---|---|
| format | missing | ⏳ Pending | - |
| test | missing | ⏳ Pending | - |
| frontend | missing | ⏳ Pending | - |
| trivy | missing | ⏳ Pending | - |
| dependency-review | missing | ⏳ Pending | - |
Automated review by ThrillhouseBot. Reply with /review to re-run.
Owner
|
/add-docs |
|
📝 ThrillhouseBot found no changed symbols that need documentation in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Owner
|
/changelog |
🤖 ThrillhouseBot — suggested CHANGELOG entryChanged
Suggestion only — nothing was committed. Copy whatever fits into |
devops-thiago
approved these changes
Jul 27, 2026
devops-thiago
added a commit
that referenced
this pull request
Jul 27, 2026
…validated Five commits landed on release/v0.5.0 after the section was written. Two changed what ships: #429 was undocumented — it widens the default ignored-files globs, which is a behavior change for existing deployments: a repo keeping handwritten source under build/, bin/, out/ or vendor/ silently stops having it reviewed. Added under Changed with that caveat called out. #423 audited the branch and altered behavior three existing entries describe: the #97 arithmetic cap became evidence-dependent rather than absolute, #324 gained collaborator and repo-scope gating plus INFO-log redaction, and #123's detector grew past its Java-shaped origins to JS/TS literals, arrow validators, package-private declarations, and multiline construction. Per the release convention, #423's own fixes get no Fixed entries — they repair code introduced in this cycle, which never reached a user. They are folded into the feature entries instead, because those describe what actually ships. Fixed still holds only pre-0.5.0 behavior: #107, #334, #336, #337. Prose kept to the existing house voice: bold marks the entry name only, never mid-sentence emphasis, matching every prior release section. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4 tasks
devops-thiago
added a commit
that referenced
this pull request
Jul 27, 2026
…validated (#430) ## What type of PR is this? - [x] 📝 Documentation ## Description Five commits landed on `release/v0.5.0` after the `[0.5.0]` section was written. Two of them changed what actually ships, leaving one feature undocumented and three entries describing behaviour that no longer exists. ### #429 was missing, and it changes existing deployments It widens the default `thrillhousebot.review.ignored-files` globs (closes #52) to cover `pnpm-lock.yaml`, `go.sum`, protobuf output, minified bundles and sourcemaps, and the directories `node_modules/`, `dist/`, `build/`, `out/`, `.next/`, `vendor/`, `__pycache__/`, `.venv/`, `bin/`, `obj/`. Filed under **Changed** rather than Added, because it is not additive for anyone already running the bot: the directory globs match by name, so a repository keeping handwritten source under `build/`, `bin/`, `out/` or `vendor/` silently stops having it reviewed on upgrade. The entry says so — the code's own javadoc carries the same warning. ### #423 invalidated three entries The audit commit touched 35 files (+2303/−159) and never touched the changelog: | Entry | Was wrong because | |---|---| | **#97** | Said the arithmetic/test-failure cap was absolute ("at most low confidence"). #423 made it evidence-dependent: with an execution or CI signal in the material, the finding keeps the confidence that evidence justifies | | **#324** | Described feedback capture with no permission model. It now records only verified write-capable collaborators on bot-authored threads, scopes `GET /api/dashboard/feedback` to repos the caller can access, bounds capture concurrency, and no longer logs source-line contents at INFO | | **#123** | Described a Java-shaped detector. It now spans JS/TS regex literals, `function`/arrow validators, package-private Java declarations, and multiline construction over a bounded window — and only confirms a synthesized failure when the expected domain or contract is visible | Also added a Dependencies line for the Node 22 requirement and the PostCSS/Sharp pins, which is what makes a clean `npm ci` resolve without known high-severity advisories. ## Related Issues N/A — release documentation accuracy. ## How Has This Been Tested? - [x] Manual testing Verified against the branch state: - every merged issue is cited except #136 (test hardening, intentional) - no intra-release fix numbers leaked in — #410, #421, #423, #428 all absent - `Fixed` audited entry by entry for pre-0.5.0 scope Prose checked against the house voice rather than written free-hand: bold marks the entry name and nothing else, matching every prior release section (0.4.0 and 0.3.x use no mid-sentence bold at all). Em dash density lands at 11.1 per 1000 words against 12.9 in 0.3.1 and 13.3 in 0.3.0, so it reads consistently with the sections around it. ## Checklist - [x] My code follows the project's coding standards - [x] I have performed a self-review of my own code
4 tasks
devops-thiago
added a commit
that referenced
this pull request
Jul 27, 2026
Release notes were built from CHANGELOG.md alone, so GitHub's generated "New Contributors" section never ran — no release from v0.3.0 onward has one. v0.5.0 would have shipped the same way, without crediting @matheusandre1 for the wider ignored-files defaults (#429). The workflow now asks the Release Notes API for the generated section and appends it after the curated notes. Generated explicitly rather than via `gh release create --generate-notes` because `gh release edit` has no equivalent flag — the existing re-run path would have overwritten the body and dropped the credit. Best-effort: a failed generation warns and publishes the CHANGELOG notes alone rather than failing the release. .github/release.yml shapes that section and excludes Dependabot and github-actions, since seven bot PRs in one release would bury the humans in both the PR list and the contributor credit; the bumps are already summarised under Dependencies. No changelog maintenance: crediting stays automatic on every future release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
devops-thiago
added a commit
that referenced
this pull request
Jul 27, 2026
…#432) ## What type of PR is this? - [x] 🏗️ CI/CD ## Description Release notes were assembled from `CHANGELOG.md` alone, so GitHub's generated **New Contributors** section never ran and outside contributors went uncredited. v0.5.0 has one: **@matheusandre1** wrote the wider default ignored-files patterns (#429). ### Workflow `gh release create` gains the generated section — but not via `--generate-notes`. The existing workflow has two paths, and `gh release edit` (the re-run path) has **no** `--generate-notes` flag, so adding it only to `create` would mean any re-run silently overwrites the body and drops the credit. Instead the notes are generated once through the Release Notes API and both paths publish the same `release_body.md`: ```bash cp release_notes.md release_body.md if generated=$(gh api "repos/${GITHUB_REPOSITORY}/releases/generate-notes" \ -f tag_name="$TAG" --jq .body 2>/dev/null) && [ -n "$generated" ]; then printf '\n\n%s\n' "$generated" >> release_body.md else echo "::warning::Could not generate release notes; publishing CHANGELOG notes only" fi ``` Best-effort by design: if generation fails the release still publishes with the curated notes and a warning, rather than failing at the last step of a release. `contents: write` and `GH_TOKEN` are already present on that step, so no permission change. ### `.github/release.yml` (new) Shapes the generated section. Excludes `dependabot` and `github-actions`: seven Dependabot PRs landed in v0.5.0 and would bury the humans in both the PR list and the contributor credit, and the bumps are already summarised under **Dependencies** in the changelog. ## Related Issues N/A — release process. ## How Has This Been Tested? - [x] Manual testing - `.github/release.yml` parses and carries the `changelog` root key GitHub expects - Confirmed `gh release edit` lacks `--generate-notes` (`gh release edit --help`), which is what drove the generate-once approach rather than the one-flag version - Confirmed the step already exports `GH_TOKEN` and the job holds `contents: write`, both required by the `generate-notes` endpoint - Contributors verified from the branch itself: `git shortlog -sne origin/main..origin/release/v0.5.0` → Thiago Gonzaga (28), dependabot (7), Matheus André (1, #429) The generated section itself can only be verified when a release is cut — the failure mode if anything is wrong is a warning plus notes-as-before, not a broken release. ## Checklist - [x] My code follows the project's coding standards - [x] I have performed a self-review of my own code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Related Issues
Closes: #52
Checklist