ci(repo-settings): use squash-merge only for clean release-please changelogs - #22
ci(repo-settings): use squash-merge only for clean release-please changelogs#22cbrgm wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughThe ChangesMerge strategy configuration
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
0bd32c7 to
ecbe4d7
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@common.mk`:
- Around line 114-118: Update the repository settings arguments in the make
target around allow_merge_commit, allow_squash_merge, and allow_rebase_merge to
use gh’s typed-field option instead of the raw-field option, ensuring true/false
values are serialized as JSON booleans while leaving string-valued fields
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| -f allow_merge_commit=false \ | ||
| -f allow_squash_merge=true \ | ||
| -f allow_rebase_merge=false \ | ||
| -f squash_merge_commit_title=PR_TITLE \ | ||
| -f squash_merge_commit_message=PR_BODY \ |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
rg -n '^\s+-f (allow_merge_commit|allow_squash_merge|allow_rebase_merge|delete_branch_on_merge|allow_auto_merge)=' common.mkRepository: opendefensecloud/dev-kit
Length of output: 354
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== common.mk context =="
sed -n '104,122p' common.mk | cat -n
echo
echo "== search for related boolean repo patches =="
rg -n 'gh api .*PATCH .*repos|allow_merge_commit|allow_squash_merge|allow_rebase_merge|delete_branch_on_merge|allow_auto_merge' -S .
echo
echo "== gh availability/version =="
if command -v gh >/dev/null 2>&1; then
gh version
gh api --help | sed -n '/--raw-field\|--typed-field/p'
else
echo "gh command not available"
fi
echo
echo "== repository settings schemas in GitHub docs? local docs? =="
rg -n 'PATCH /repos/{owner}/{repo}|allow_merge_commit|delete_branch_on_merge|type.*true|type.*false' -S . || trueRepository: opendefensecloud/dev-kit
Length of output: 1832
🌐 Web query:
GitHub CLI gh api -f vs -F raw-field typed-field boolean fields
💡 Result:
In the GitHub CLI (gh), the --field (-F) and --raw-field (-f) flags behave differently regarding how they handle data types like booleans and numbers [1][2]. --field (-F) (Typed Field): This flag supports magic type conversion based on the value provided [1]. When you use -F, the GitHub CLI attempts to interpret specific literal values as their corresponding JSON types [1]. - Booleans: Values like true and false are automatically converted to JSON boolean types [1]. - Numbers: Integer numbers are converted to JSON number types [1]. - Null: The value null is converted to a JSON null type [1]. --raw-field (-f) (Raw Field): This flag treats all values as static strings [1][2]. It does not perform any automatic type conversion or JSON parsing on the value [2]. If you need a value to be treated strictly as a string—even if it looks like a boolean or number—you should use --raw-field [2]. Summary of Key Differences: - Use --field (-F) when you want the CLI to automatically handle JSON type conversion for booleans, numbers, and null values [1]. - Use --raw-field (-f) when you want to ensure the value is sent as a string [2]. - For complex data structures such as nested objects or arrays, neither flag is typically sufficient on its own [3][4]. In such cases, the recommended practice is to prepare the full JSON payload externally and pass it to the command using --input - (reading from standard input) or a file [1][3][4]. Example Usage: # Using -F for automatic type conversion (sends JSON boolean) gh api -X PATCH /repos/{owner}/{repo} -F archived=true # Using -f for string-only (sends "true" as a string, if the API expects a string) gh api -X PATCH /repos/{owner}/{repo} -f archived="true"
Citations:
- 1: https://cli.github.com/manual/gh_api
- 2: https://www.ayokoding.com/en/learn/software-engineering/automation-tools/gh-cli/by-example/advanced
- 3: Add note on supported value types in raw-fields cli/cli#3400
- 4: Allow JSON array parameters in
gh apicli/cli#1484
🌐 Web query:
GitHub REST API update repository PATCH body allows auto merge allow squash merge merge commit true false boolean
💡 Result:
The GitHub REST API update repository endpoint (PATCH /repos/{owner}/{repo}) supports the following boolean parameters to control merge settings, which must be passed in the request body [1]: - allow_squash_merge (boolean): Set to true to allow squash-merging pull requests, or false to prevent it. The default value is true [1]. - allow_merge_commit (boolean): Set to true to allow merging pull requests with a merge commit, or false to prevent it. The default value is true [1]. - allow_auto_merge (boolean): Set to true to allow auto-merge on pull requests, or false to disallow it. The default value is false [1]. These parameters allow you to programmatically toggle repository merge configurations by sending the desired boolean value in your JSON request body [1].
Citations:
🌐 Web query:
GitHub REST API update repository PATCH allow_rebase_merge boolean merge commit
💡 Result:
To update repository settings using the GitHub REST API, you can use the PATCH /repos/{owner}/{repo} endpoint [1][2]. The allow_rebase_merge parameter is a boolean value that controls whether rebase-merging of pull requests is enabled for the repository [1][3]. Setting this to true allows rebase-merging, while false prevents it [1][4]. The default value for this setting is true [1][3]. When updating repository merge settings, you can also configure related options using the same PATCH endpoint, such as: allow_merge_commit (boolean): Enables or disables merging pull requests with a merge commit (default: true) [3][2]. allow_squash_merge (boolean): Enables or disables squash-merging of pull requests (default: true) [2][5]. For example, a JSON request body to update these settings would look like this: { "allow_merge_commit": true, "allow_squash_merge": true, "allow_rebase_merge": false } Note that managing repository merge settings requires the contents:read and contents:write permissions [2][5]. While this PATCH endpoint manages overall repository settings, actual pull request merges are performed using the PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge endpoint, which accepts a merge_method parameter (merge, squash, or rebase) [6].
Citations:
- 1: https://docs.github.com/en/rest/repos/repos
- 2: https://docs.github.com/en/rest/repos/repos?apiVersion=2026-03-10
- 3: https://docs.github.com/enterprise-server@2.22/rest/reference/repos
- 4: https://www.simworkflow.com/integration-operation/github-repos-owner-repo-patch-f36
- 5: https://docs.github.com/en/enterprise-cloud@latest/rest/repos/repos
- 6: https://docs.github.com/en/rest/pulls/pulls
Use typed fields for boolean repository settings.
gh api -f/--raw-field sends literal string values, but the repository PATCH fields here are defined as booleans. Use -F/--typed-field so false/true are serialized as JSON booleans; otherwise the settings update can fail validation.
Proposed fix
- -f allow_merge_commit=false \
- -f allow_squash_merge=true \
- -f allow_rebase_merge=false \
+ -F allow_merge_commit=false \
+ -F allow_squash_merge=true \
+ -F allow_rebase_merge=false \
-f squash_merge_commit_title=PR_TITLE \
-f squash_merge_commit_message=PR_BODY \
- -f delete_branch_on_merge=true \
- -f allow_auto_merge=true > /dev/null; \
+ -F delete_branch_on_merge=true \
+ -F allow_auto_merge=true > /dev/null; \📝 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.
| -f allow_merge_commit=false \ | |
| -f allow_squash_merge=true \ | |
| -f allow_rebase_merge=false \ | |
| -f squash_merge_commit_title=PR_TITLE \ | |
| -f squash_merge_commit_message=PR_BODY \ | |
| -F allow_merge_commit=false \ | |
| -F allow_squash_merge=true \ | |
| -F allow_rebase_merge=false \ | |
| -f squash_merge_commit_title=PR_TITLE \ | |
| -f squash_merge_commit_message=PR_BODY \ | |
| -F delete_branch_on_merge=true \ | |
| -F allow_auto_merge=true > /dev/null; \ |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@common.mk` around lines 114 - 118, Update the repository settings arguments
in the make target around allow_merge_commit, allow_squash_merge, and
allow_rebase_merge to use gh’s typed-field option instead of the raw-field
option, ensuring true/false values are serialized as JSON booleans while leaving
string-valued fields unchanged.
2 participants
What
Switches the
repo-settingstarget from merge-commit to squash-merge only, and sets the squash commit message to the PR title/body.allow_merge_commit:true->falseallow_squash_merge:false->truesquash_merge_commit_title=PR_TITLE+squash_merge_commit_message=PR_BODYWhy
With merge commits, a PR's feature-branch commits land on
mainnext to the merge commit, and both carry Conventional-Commit messages. release-please walks the whole history and lists both, so every change shows up twice in the changelog. Squash-merge gives exactly one Conventional commit per PR onmain= one changelog entry. ThePR_TITLE/PR_BODYsquash message keeps the squash subject as the Conventional commit and avoids release-please re-parsing the per-commit list that the defaultCOMMIT_MESSAGESbody would include.This surfaced on solution-arsenal's first release-please changelog (0.3.0), which was full of duplicates.
Notes
Consumers pick this up on their next
.common.mk-versionbump, so this needs a new dev-kit tag to roll out.allow_rebase_merge,delete_branch_on_merge,allow_auto_mergeare unchanged.Summary by CodeRabbit