Repository navigation
gh ruleset should offer export and import #8019
Description
Activity
@vaindil can I get your 👀 on this please? It seems like an interesting use case to me but I'm not particularly familiar with the ruleset offering.
For some context, a
createsubcommand was originally not added because creating a ruleset is just too complex of an operation to really support interactively. You'd essentially have to pass the API endpoint's raw JSON payload into the subcommand, at which point there's no real benefit over usinggh api. There was some discussion about accepting YAML input that's transformed into the correct JSON, but that would likely end up too complex for no major benefit.My gut reaction is that this feature request would probably be simple enough to do:
exportsubcommand dumps the full body of the "Get a repository ruleset" REST API endpointimportsubcommand accepts a file path, destination (either org or repo), and name, then grabs the JSON in the file, tweaks it as needed, and passes it directly to the "Create a ruleset" REST API endpoint
This would limit the CLI's role to just transforming the JSON from one endpoint to the other, which shouldn't be too large of a scope.
My only concern is that rulesets are still in active development and more features are in the works, so the API shape will likely change enough that the CLI has to be updated when these new features roll out. This isn't inherently a problem, but it's just something to keep in mind because it ties the CLI to the shape of the feature a bit more tightly than the other CLI features I'm familiar with.
Thanks for the explanation and historical context.
My only concern is that rulesets are still in active development and more features are in the works, so the API shape will likely change enough that the CLI has to be updated when these new features roll out. This isn't inherently a problem, but it's just something to keep in mind because it ties the CLI to the shape of the feature a bit more tightly than the other CLI features I'm familiar with.
Can you describe some of the changes the API might make that might require a CLI change? I'm thinking these APIs are versioned and shouldn't be introducing breaking changes right? If it is a problem, perhaps an extension would be a natural place for this to live until things stabilise.
I checked with the rulesets team, and they're actually currently working on import/export via the UI. There are tentative plans for API endpoints to support this as well, but those are still in the earlier stages so no promises on a timeline.
The CLI could add support now using the process I put above and swap over to the new endpoints if/when they're added, but it probably makes more sense to wait a bit to see what happens.
Ok I'm going to keep this open so that it is visible, and label it with
coreuntil we get more clarity on what the team are going to do.@jsoref : How would this request work with organizational repository rulesets?
I could see this feature being necessary for duplicating organization repository rulesets across enterprises with 100s of organizations. Otherwise, I would configure select repositories at the organizational repository ruleset.
Reacted by Jason FlahertyAssuming ruleset patterns only include repository names and not the owners, I don't see a problem in including that in the output or consumed input.
My starting point is a repository (jsoref/check-spelling) that's a fork of an upstream (check-spelling/check-spelling). Before I deploy changes to the upstream, I try to test them in my fork.
Beyond that, I control a handful of organizations and being able to copy rulesets across them seems incredibly handy.
For example, I could definitely see the value in writing a ruleset that applied to
.githuband.github-private.Reacted by Jason Flaherty and Andy BarillaI would really like this, it would help me automate initial setups of repos that we internally create from templates(they're not forks so they don't inherit this)
Currently it's still a manual setup
Reacted by Elliot Maincourt, Andy Barilla and ZHANG YuntianExample bash script for how we update exported ruleset with
gh api:if ! gh api --method POST -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" \ "/repos/$ORGANIZATION/$TARGET/rulesets" --input "default.json"; then local RULESET_ID RULESET_ID="$(gh api -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" \ "/repos/$ORGANIZATION/$TARGET/rulesets" --jq '.[] | select(.name = "default").id')" gh api --method PUT -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" \ "/repos/$ORGANIZATION/$TARGET/rulesets/$RULESET_ID" --input "default.json" fi- added a commit that references this issue
on May 29, 2026 - added 6 commits that reference this issue
on May 29, 2026
Describe the feature or problem you’d like to solve
I have built a ruleset for a repository in one owner (for testing) and would like to copy it to another repository (in this case, a fork-related repository, although as my rules are fairly generic, i'd probably like to be able to copy it generally).
Proposed solution
Something like:
gh ruleset view --repo jsoref/check-spelling 94531 --format=json > ruleset.jsonShould allow generating a format that could be consumed.
Something like
Should allow consuming the ruleset.
How will it benefit CLI and its users?
Users could copy rulesets from one repository to another or even a template ruleset from the web.
Additional context
https://jessehouwing.net/protect-the-repository-hosting-your-github-action/ has graphical instructions for creating rulesets, but it's quite tedious to do it for even a single repository, and it'd be much nicer if the instructions just gave a cli for creating the rules.