Repository navigation
Add repositories to Renovate config - #4010
Conversation
|
Warning Review limit reached
Next review available in: 38 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: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
✨ 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 |
Extension Size Change: -3.63 KB ✅
This commit looks good, cheers 👏 |
|
@sourcery-ai review |
Reviewer's GuideConfigures self-hosted Renovate to explicitly target this repository and incorporates the resulting automated upgrades: a pnpm major version bump, catalog dependency updates, and a small GitHub Actions release workflow update. Sequence diagram for updated release workflow using next-release-tag v6.5.0sequenceDiagram
actor Developer
participant GitHubActions
participant next_release_tag_action
Developer ->> GitHubActions: [push to default branch]
GitHubActions ->> next_release_tag_action: next-release-tag
next_release_tag_action -->> GitHubActions: release_tag output
GitHubActions -->> Developer: created tag based on release_tag
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue
Fixed security issues:
- fast-xml-parser (link) · Dashboard
- minimatch (link) · Dashboard
- node-forge (link) · Dashboard
- protobufjs (link) · Dashboard
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path=".github/workflows/release.yml" line_range="189" />
<code_context>
- name: Generate Release Tag
id: release_tag
- uses: amitsingh-007/next-release-tag@v6.3.0
+ uses: amitsingh-007/next-release-tag@v6.5.0
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Consider pinning the GitHub Action to a commit SHA for better supply-chain security.
Using a moving tag means future changes to that tag can alter your workflow without explicit review. Prefer pinning to a specific commit, e.g. `uses: amitsingh-007/next-release-tag@<commit-sha>` (optionally with a comment noting the version), so updates only occur when you intentionally change the reference.
Suggested implementation:
```
- name: Generate Release Tag
id: release_tag
# amitsingh-007/next-release-tag v6.5.0
uses: amitsingh-007/next-release-tag@<commit-sha-for-v6.5.0>
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
tag_prefix: 'v'
```
1. Replace `<commit-sha-for-v6.5.0>` with the actual commit SHA from the `amitsingh-007/next-release-tag` repository that corresponds to the `v6.5.0` release (e.g. by checking the GitHub Releases or tags page).
2. Optionally, establish a team convention that future action updates follow this pattern: update the SHA and the comment together when bumping the version.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
|
||
| - name: Generate Release Tag | ||
| id: release_tag | ||
| uses: amitsingh-007/next-release-tag@v6.3.0 |
There was a problem hiding this comment.
🚨 suggestion (security): Consider pinning the GitHub Action to a commit SHA for better supply-chain security.
Using a moving tag means future changes to that tag can alter your workflow without explicit review. Prefer pinning to a specific commit, e.g. uses: amitsingh-007/next-release-tag@<commit-sha> (optionally with a comment noting the version), so updates only occur when you intentionally change the reference.
Suggested implementation:
- name: Generate Release Tag
id: release_tag
# amitsingh-007/next-release-tag v6.5.0
uses: amitsingh-007/next-release-tag@<commit-sha-for-v6.5.0>
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
tag_prefix: 'v'
- Replace
<commit-sha-for-v6.5.0>with the actual commit SHA from theamitsingh-007/next-release-tagrepository that corresponds to thev6.5.0release (e.g. by checking the GitHub Releases or tags page). - Optionally, establish a team convention that future action updates follow this pattern: update the SHA and the comment together when bumping the version.
|
@CodiumAI-Agent /review |
Summary
Self-hosted Renovate doesn't auto-detect the repo — it needs
repositoriesexplicitly listed. Without it, the workflow logs show:This adds
"repositories": ["amitsingh-007/bypass-links"]to.github/renovate-config.jsonso the Action processes the correct repo.Greptile Summary
This PR fixes the self-hosted Renovate configuration by adding the
repositoriesfield to.github/renovate-config.json, and bundles in the resulting automated dependency updates that Renovate generated once the runner began processing the repo correctly."repositories": ["amitsingh-007/bypass-links"]so the self-hosted Renovate Action knows which repo to manage, resolving the "No repositories found" warning.packageManageradvances from10.30.3to11.0.7, a major version change;pnpm-lock.yamlandpnpm-workspace.yamlare updated in sync.@base-ui/react,@playwright/test,vite,turbo,zustand,wretch, and others), and thenext-release-tagaction moves fromv6.3.0tov6.5.0.Confidence Score: 4/5
Safe to merge; the Renovate config fix is correct, and dependency updates are routine, though the pnpm major version jump warrants a passing look at CI results.
The Renovate config change is minimal and accurate. The pnpm upgrade from v10 to v11 is the most notable change since major versions can carry breaking changes; the lock file and workspace config are updated in sync, but it's worth confirming CI passes cleanly before merging. All other dependency updates are minor or patch releases with low risk.
No files require special attention beyond confirming that CI passes with pnpm v11.
Reviews (1): Last reviewed commit: "Add repositories to Renovate config" | Re-trigger Greptile
Summary by Sourcery
Configure Renovate to explicitly target this repository and apply the resulting tooling and dependency updates across the workspace.
New Features:
Enhancements:
Build:
CI: