Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdds a CONTRIBUTING.md documentation file and a Go-based automation that embeds the template and deploys it (with repository-name substitution) to repositories via a new AddContributingGuide function invoked across repository setup flows. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
files/CONTRIBUTING.md
Outdated
| ## Getting Started | ||
|
|
||
| 1. Fork the repository | ||
| 2. Create a feature branch from `main` |
There was a problem hiding this comment.
Should this be develop or "the default branch"
There was a problem hiding this comment.
The default branch, the one that shows up on the homepage of the repository above the files in the branch selection drop down.
There was a problem hiding this comment.
Except for the holochain repo, which isn't managed by Pulumi, the default branch is main in nearly all repos. Could say "the default branch (usually main)".
🍹
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
files/CONTRIBUTING.md (1)
17-18: Minor: Capitalize "Markdown" as a proper noun."Markdown" refers to the markup language and is typically capitalized.
📝 Suggested fix
- Use [conventional commits](https://www.conventionalcommits.org/) for commit - messages. You can also use markdown, especially in the body + messages. You can also use Markdown, especially in the body🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@files/CONTRIBUTING.md` around lines 17 - 18, Update the sentence fragment "Use [conventional commits](https://www.conventionalcommits.org/) for commit messages. You can also use markdown, especially in the body" to capitalize "Markdown" as a proper noun (i.e., change "markdown" to "Markdown") so the line reads that Markdown can be used in the body; keep the rest of the sentence and link unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@files/CONTRIBUTING.md`:
- Around line 17-18: Update the sentence fragment "Use [conventional
commits](https://www.conventionalcommits.org/) for commit messages. You can also
use markdown, especially in the body" to capitalize "Markdown" as a proper noun
(i.e., change "markdown" to "Markdown") so the line reads that Markdown can be
used in the body; keep the rest of the sentence and link unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5aaef698-7d4c-40d3-9df9-849973ac6795
📒 Files selected for processing (2)
files/CONTRIBUTING.mdmain.go
files/CONTRIBUTING.md
Outdated
| ## Getting Started | ||
|
|
||
| 1. Fork the repository | ||
| 2. Create a feature branch from `main` |
There was a problem hiding this comment.
The default branch, the one that shows up on the homepage of the repository above the files in the branch selection drop down.
files/CONTRIBUTING.md
Outdated
| a re-approval is required | ||
| - Squash all `fixup!` commits and clean-up the commit history before merging | ||
| into the base branch. You can do this at the same time as rebasing with | ||
| `git rebase --autosquash <base_branch>` |
There was a problem hiding this comment.
This doesn't work for me, I always use -i at the same time. Maybe I'm doing something wrong there :)
There was a problem hiding this comment.
It works for me on macos and Linux. You must be doing something wrong! 😛
There was a problem hiding this comment.
What version of Git are you on @ThetaSinner? It seems that the --interactive requirement was removed in Git v2.44.0. Released in January 2025, maybe you should update but maybe I should also add this note in the doc?
files/CONTRIBUTING.md
Outdated
| ## Getting Started | ||
|
|
||
| 1. Fork the repository | ||
| 2. Create a feature branch from `main` |
There was a problem hiding this comment.
Except for the holochain repo, which isn't managed by Pulumi, the default branch is main in nearly all repos. Could say "the default branch (usually main)".
files/CONTRIBUTING.md
Outdated
| a re-approval is required | ||
| - Squash all `fixup!` commits and clean-up the commit history before merging | ||
| into the base branch. You can do this at the same time as rebasing with | ||
| `git rebase --autosquash <base_branch>` |
There was a problem hiding this comment.
It works for me on macos and Linux. You must be doing something wrong! 😛
Co-authored-by: Jost <28270981+jost-s@users.noreply.github.com>
feat: add contributing guide to repos that support release integration
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
main.go (1)
112-114: Reduce drift risk by bundling release-integration setup with contributing-guide setup.This repeated two-call sequence is easy to miss in future repo additions. Consider a single helper that does both, then call that helper everywhere.
♻️ Proposed refactor
+func AddReleaseIntegrationSupportWithContributingGuide(ctx *pulumi.Context, cfg *config.Config, name string, repository *github.Repository) error { + if err := AddReleaseIntegrationSupport(ctx, cfg, name, repository); err != nil { + return err + } + return AddContributingGuide(ctx, name, repository) +}- if err = AddReleaseIntegrationSupport(ctx, conf, "tx5", tx5); err != nil { - return err - } - if err = AddContributingGuide(ctx, "tx5", tx5); err != nil { + if err = AddReleaseIntegrationSupportWithContributingGuide(ctx, conf, "tx5", tx5); err != nil { return err }Also applies to: 164-166, 321-323, 351-353, 381-383, 411-413, 441-443, 471-473, 587-589, 659-661, 851-853, 1008-1010, 1035-1037, 1368-1370
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@main.go` around lines 112 - 114, The two-call sequence that invokes AddContributingGuide(...) followed immediately by the release-integration setup is repeated across the codebase and risks drift; create a single helper (e.g., AddContributingAndReleaseSetup(ctx, repoName, repoConfig)) that internally calls AddContributingGuide(...) and the existing release-integration function (the release-integration setup currently paired with AddContributingGuide calls) and returns an error if either fails, preserving existing error handling; then replace each pair of calls (instances around AddContributingGuide(...) at lines like the shown one and the other listed locations) with a single call to AddContributingAndReleaseSetup(...) to centralize behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@files/CONTRIBUTING.md`:
- Line 18: Update the user-facing copy that reads "You can also use markdown,
especially in the body" to capitalize the proper noun "Markdown" (i.e., change
"markdown" to "Markdown") so the CONTRIBUTING guidance consistently uses the
correct form.
---
Nitpick comments:
In `@main.go`:
- Around line 112-114: The two-call sequence that invokes
AddContributingGuide(...) followed immediately by the release-integration setup
is repeated across the codebase and risks drift; create a single helper (e.g.,
AddContributingAndReleaseSetup(ctx, repoName, repoConfig)) that internally calls
AddContributingGuide(...) and the existing release-integration function (the
release-integration setup currently paired with AddContributingGuide calls) and
returns an error if either fails, preserving existing error handling; then
replace each pair of calls (instances around AddContributingGuide(...) at lines
like the shown one and the other listed locations) with a single call to
AddContributingAndReleaseSetup(...) to centralize behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 28208112-f4ad-4a31-ab22-f0c1ae460693
📒 Files selected for processing (2)
files/CONTRIBUTING.mdmain.go
files/CONTRIBUTING.md
Outdated
| them clean. To help with keeping them clean, follow these principles: | ||
|
|
||
| - Use [conventional commits](https://www.conventionalcommits.org/) for commit | ||
| messages. You can also use markdown, especially in the body |
There was a problem hiding this comment.
Capitalize Markdown in commit guidance.
Use the proper noun form for consistency in user-facing docs.
✏️ Proposed fix
-- messages. You can also use markdown, especially in the body
+- messages. You can also use Markdown, especially in the body📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| messages. You can also use markdown, especially in the body | |
| messages. You can also use Markdown, especially in the body |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~18-~18: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...for commit messages. You can also use markdown, especially in the body - Keep commits ...
(MARKDOWN_NNP)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@files/CONTRIBUTING.md` at line 18, Update the user-facing copy that reads
"You can also use markdown, especially in the body" to capitalize the proper
noun "Markdown" (i.e., change "markdown" to "Markdown") so the CONTRIBUTING
guidance consistently uses the correct form.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
files/CONTRIBUTING.md (1)
18-18:⚠️ Potential issue | 🟡 MinorCapitalize “Markdown” in commit guidance.
Line 18 uses “markdown”; use the proper noun “Markdown” for consistency in user-facing docs.
✏️ Proposed fix
- messages. You can also use markdown, especially in the body + messages. You can also use Markdown, especially in the body🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@files/CONTRIBUTING.md` at line 18, Change the lowercase word "markdown" in the CONTRIBUTING.md text (the instance shown in the diff) to the proper noun "Markdown" so the user-facing guidance uses correct capitalization; locate the token "markdown" and replace it with "Markdown".
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@files/CONTRIBUTING.md`:
- Around line 42-44: Update the sentence about rebasing after approval to
clarify that only UI rebases always preserve approvals and that local rebases
may require re-approval depending on the repository's branch protection setting;
reword the existing lines to something like: "After an approval, rebase on the
base branch. Rebasing via the GitHub UI preserves approvals. However, local
rebases may trigger re-approval depending on the repository's branch protection
settings (the 'dismiss stale pull request approvals' option)." Make sure the new
text replaces the current paragraph that discusses UI vs local rebase behavior
and explicitly mention the "dismiss stale pull request approvals" setting.
---
Duplicate comments:
In `@files/CONTRIBUTING.md`:
- Line 18: Change the lowercase word "markdown" in the CONTRIBUTING.md text (the
instance shown in the diff) to the proper noun "Markdown" so the user-facing
guidance uses correct capitalization; locate the token "markdown" and replace it
with "Markdown".
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2b8cd8ea-2fb9-43ef-9393-48c9cb6e67db
📒 Files selected for processing (1)
files/CONTRIBUTING.md
files/CONTRIBUTING.md
Outdated
| - After an approval, rebase on the base branch. If this is done via the GitHub | ||
| UI then no re-approval will be needed. However, if this is done locally then | ||
| a re-approval is required |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In GitHub pull requests, does rebasing via the GitHub UI always avoid requiring re-approval, or does this depend on branch protection settings (e.g., dismiss stale approvals)?
💡 Result:
Rebasing a pull request branch via the GitHub UI (using "Update with rebase" or "Rebase branch") does not always require re-approval. It depends on the branch protection settings, specifically the "Dismiss stale pull request approvals when new commits are pushed" option. If this setting is enabled on the base branch's protection rule, pushing new commits (including those from a UI rebase, which rewrites history and force-pushes) that are considered "reviewable" will dismiss existing approvals, requiring re-approval. However, GitHub treats UI-performed rebases (and merges from the base branch) as non-reviewable updates. These do not trigger dismissal of approvals, preserving them even with the dismiss stale setting enabled. Manual pushes, local rebases with force-push, or other web changes (e.g., applying suggestions) are treated as reviewable and dismiss approvals. This behavior is confirmed by user observations and expert explanations: UI rebase onto the base branch avoids dismissal, while manual rebases do not, due to GitHub's special handling of its own sync tools.
Citations:
- 1: https://stackoverflow.com/questions/74200763/using-github-branch-protection-how-does-github-define-a-stale-pull-request-appr
- 2: https://docs.github.com/en/enterprise-server@3.2/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches
- 3: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/keeping-your-pull-request-in-sync-with-the-base-branch
- 4: https://github.blog/changelog/2022-02-02-more-ways-to-keep-your-pull-request-branch-up-to-date
Clarify that re-approval requirement for local rebases depends on repository settings.
Lines 42-44 are mostly accurate based on GitHub's actual behavior: UI-performed rebases preserve approvals (GitHub treats them as non-reviewable), while local rebases may trigger approval dismissal—but only if the repository has enabled the "dismiss stale pull request approvals" branch protection setting. Reword to clarify the local rebase behavior is settings-dependent, not absolute; however, avoid implying the GitHub UI rebase is also conditional, since it consistently preserves approvals regardless of branch protection settings.
✏️ Suggested reword
Instead of the proposed fix, consider:
- After an approval, rebase on the base branch. Rebasing via the GitHub UI
- preserves approvals. However, local rebases may trigger re-approval depending
- on the repository's branch protection settings (the "dismiss stale pull request
- approvals" option).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@files/CONTRIBUTING.md` around lines 42 - 44, Update the sentence about
rebasing after approval to clarify that only UI rebases always preserve
approvals and that local rebases may require re-approval depending on the
repository's branch protection setting; reword the existing lines to something
like: "After an approval, rebase on the base branch. Rebasing via the GitHub UI
preserves approvals. However, local rebases may trigger re-approval depending on
the repository's branch protection settings (the 'dismiss stale pull request
approvals' option)." Make sure the new text replaces the current paragraph that
discusses UI vs local rebase behavior and explicitly mention the "dismiss stale
pull request approvals" setting.
|
❌ Found 2 compliant commit and 6 non-compliant commits in 885d3be...6f04744. Commit ee472ff by @cdunster is not conform to the conventional commit specification :
Co-authored-by: Jost 28270981+jost-s@users.noreply.github.com`
Commit 5a64278 by @cdunster is not conform to the conventional commit specification :
Commit 103a55e by @cdunster is not conform to the conventional commit specification :
Commit 1b28e9f by @cdunster is not conform to the conventional commit specification :
feat: add contributing guide to repos that support release integration`
Commit f781017 by @cdunster is not conform to the conventional commit specification :
Commit 6f04744 by @cdunster is not conform to the conventional commit specification :
|
3 participants
Add a function to create a CONTRIBUTING.md guidelines file in the repos that use the release integration tooling.
Summary by CodeRabbit
New Features
Documentation