Custom properties missing in GHRepository

[nardew]

Describe the bug GHRepository class (interface to repos/org/repo_name GitHub endpoint) is missing custom properties. They are mentioned in the GitHub documentation at the root level as

"custom_properties": {
      "type": "object",
      "description": "The custom properties that were defined for the repository. The keys are the custom property names, and the values are the corresponding custom property values.",
      "additionalProperties": true
    }

[bitwiseman]

PR welcome.

[gitPushPuppets]

I've got a working local poc for GET /repos/{owner}/{repo}/properties/values and have started exploring the POST for create or update. @bitwiseman, do you have advise on how I should architect this? The response body of the GET and request body of the POST are slightly different and custom properties also exist at the org level. I am considering modeling my Custom Properties solution off of GHHooks.

[bitwiseman]

@gitPushPuppets I'm sorry, I don't have a lot of bandwidth. Please create a PR with what you have (even rough and without tests, heck even if it doesn't build) and we can start discussion that way. Once I see what you've written, we can figure out if we need to have a real-time chat. Okay?

[bitwiseman]

• https://docs.github.com/en/enterprise-cloud@latest/rest/orgs/custom-properties?apiVersion=2022-11-28 - Organization custom properties. This same API can also update repositories in an organization (with some limitations).
• https://docs.github.com/en/enterprise-cloud@latest/rest/repos/repos?apiVersion=2022-11-28#create-an-organization-repository - mentions custom_properties as an optional parameter

[gitPushPuppets]

Sounds good

On Thu, Dec 5, 2024 at 4:08 PM Liam Newman @.***> wrote:

@.***/rest/orgs/custom-properties?apiVersion=2022-11-28

• Organization custom properties. This same API can also update repositories in an organization (with some limitations).

@.***/rest/repos/repos?apiVersion=2022-11-28#create-an-organization-repository

• mentions custom_properties as an optional parameter

— Reply to this email directly, view it on GitHub https://github.com/hub4j/github-api/issues/1847#issuecomment-2521569143, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZT3PXX3A5SW5PQYTGWIN32EDFHVAVCNFSM6AAAAABSRVVY5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRRGU3DSMJUGM . You are receiving this because you were mentioned.Message ID: @.***>

[gitPushPuppets]

I explored these as well. The custom props are created and designed at the org level with some nice datatype functionality.

The repos in an org will have all custom properties on them and will either be null or set to the default value defined by the org props definition.

I started testing using the same object for get and post but github uses slightly different objects.

GET

[ { "property_name": "branch-protection-rulesets", "value": "true" }, { "property_name": "team", "value": "java" } ]

POST

{ "properties": [ { "property_name": "branch-protection-rulesets", "value": "true" }, { "property_name": "team", "value": "java" } ] }

[bitwiseman]

I started testing using the same object for get and post but github uses slightly different objects.

The child objects looks the same, so that's good. I wouldn't expected the GET and POST calls to have the same structure. I don't think there's much advantage to it as long as the child objects match.