Closed Simon-Boyer closed 4 months ago
I'm not sure safe-settings should create properties that don't exist (since there are already two types) but it would be great if it could set properties that already exist. Until there are better tools in the UI for enforcing that repositories get particular properties this will be a great way to ensure everything is set correctly.
I'm not sure when, but Github added the possibility to set custom properties in the create repository request: https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#update-a-repository.
Since safe-settings sends the repo object directly to that api call, i tried setting it in the repo yml file like this:
repository:
custom_properties:
foo: bar
And it worked at creation, but it does not work if I then change the custom property value. It looks like github doesnt have (yet?) the same custom_properties attribute for a PATCH request: https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#update-a-repository
Prerequisites:
Is the functionality available in the GitHub UI? If so, please provide a link to information about the feature. https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization
Is the functionality available through the GitHub API? If the functionality is available, please provide links to the API documentation (https://developer.github.com/v3/) as well as the Octokit documentation (https://octokit.github.io/). https://docs.github.com/en/rest/repos/properties?apiVersion=2022-11-28 https://docs.github.com/en/rest/orgs/custom-properties?apiVersion=2022-11-28
New Feature
Support configuring the new repository custom properties in a repository config. This feature is really useful to setup different rulesets according to language, environments, compliance requirements etc. I already have a client that would use this feature and would prefer to be able to do it through safe-settings.
It could look something like this:
If the property does not already exists at the org level, it should create it before setting the property. Only supporting text properties is fine since input validation can be done on the safe-settings files themselves.