Repository Custom Properties Beta Feedback

[chrispat]

I’m excited to announce that Repository Custom Properties are in Beta! 🎉

Starting today, organization administrators can create custom properties to enrich repositories with valuable information. Using these properties, you can dynamically target repository rules to apply protections on just your production repositories or to a business unit or any other way you want to classify your repositories.

Checkout the docs to learn more

❔ Still have questions?

• Feel free to post here for feedback.
• For bugs or deeper questions please reach out to support.

[shyim]

I would like to use Custom Properties to say X devs are maintainers of this repository. To do that, I would need as Type Multi Select.
As workaround it's possible to use the text field with separator, but in future it would be nice to have Multi selects

[chrispat]

Are you looking to list the names of the developers? Could you provide some examples of how you would expect someone to use this information?

[lucien-heart]

Wonderful!

[neilzhao-aws]

I just tried the custom properties and my actions doesn't have record in audit log.
Can you add audit log types for this feature please?

[sbauer]

Thanks for the feedback! Property changes should now be in your org's audit log.

[Thunderforge]

The documentation does not provide many examples of actual use cases for custom properties. You set them up and then what? I guess you can search on them, and apparently you can use them for rulesets (the documentation is pretty vague though. What does it mean to "target" them?).

More examples of applied use cases would help.

[chrispat]

Common use cases we have seen during the alpha are things like, compliance_level, department, contains_pii. As we see more usage from customers, we will follow up with some articles outlining common use cases.

[Jesson1018]

Hopefully GitHub can put more details for the connection between 'custom properties' and 'rulesets', and demonstrates more useful cases in the documentation. Thanks.

[djonser]

Are there any plans to include these properties as claims in the GitHub Actions OIDC access token?

[zachariahcox]

👍 I think that's the right kind of direction. Mechanically, that token has strict size limitations and we have lots of claims we could make. Stay tuned!

[djonser]

I guess that if this capability is provided 🤞 it will be with the ability to toggle which properties should be included in the access token and some kind of quota for how many properties is allowed to be included? Would not want the custom properties feature artificially constrained by access token limitations by requiring all properties to also be claims.

Great feature many of us have wished for and glad to hear about the direction! Thanks for taking the time. I'm Staying tuned.

[chrispat]

They will be in the webhook payload as well.

[liaodaniel]

@chrispat can I confirm if the custom_properties field is going to be included in every webhook payload? I can see the field in most of the events (e.g. workflow_job, push, pull_request, issue_comment, etc) but the docs https://docs.github.com/en/webhooks/webhook-events-and-payloads haven't yet reflected the change.

[marciorgb]

The custom props are available to the GH API? It would be nice to filter repos by props.

And in the future can we select repos to run required workflows using props, like in the rulesets?

[chrispat]

API docs should be up now. And you can use properties to target rulesets today.

[Jesson1018]

Could you share some use cases for 'target rulesets'? I am trying to find out some docs but unfortunately I don't get.

[jmaixl]

The docs say that we can already filter by property: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization#searching-and-filtering-repositories-by-custom-properties-values

Is this premature?

[chrispat]

Yes that should have been left out of the docs, but it is coming soon.

[mblack88]

@chrispat Any updated when the searching will be available?

[ReenigneArcher]

Interesting... I've been using repository "topics" to automate based on whether the "topic" is there or not... custom properties seems like a much better approach.

[arnested]

I just had a quick go at it:

• Could the custom properties be added to, e.g., the github.event.repository context in GitHub Action workflows?
• I couldn't add a value with a @ in it (an email address).

[chrispat]

Could the custom properties be added to, e.g., the github.event.repository context in GitHub Action workflows?

This is in progress.

I couldn't add a value with a @ in it (an email address).

We are looking removing some of the restrictions on values.

[corydolphin]

That's great! Having support for access to the custom properties of the target repo in Github Actions will really enable us to make use of these for enforcement of organization wide defaults.

[chrispat]

This has rolled out. You can reference a property value using the event context

github.event.repository.custom_properties.

[speter04]

Looking forward to the feature to add email IDs to custom properties (adding @ symbol).

[BenjaminYde]

It would be cool to filter in a github project on a repository property of an issue
in the filter tab: repo-property:"<property-name>:<property-value>"

[Jesson1018]

Could you please paste a snapshot for reference? Thanks.

[akbast]

It would be cool to access those properties within workflows like secrets or variables, like ${{ props.ABC }}. This would make the usage of custom properties easier within CI/CD pipelines.

[akbast]

The properties should stay editable only by the org admins. If there are plans to change this and allow repo admins also to change those, it would be cool that the properties can be configured as restricted.

[chrispat]

It would be cool to access those properties within workflows like secrets or variables, like ${{ props.ABC }}. This would make the usage of custom properties easier within CI/CD pipelines.

This is in progress. The properties will be part of the repository object in webhook payloads.

This has rolled out. You can access properties in the event context github.event.repository.custom_properties.

[jmaixl]

I was going to switch from topics to properties, but apparently you need to be an organization owner to set properties, while topics can be set by maintainers.

It would be great to create a permission to set properties for maintainers and above.

[Utsav2]

Is this available on all GitHub plans?

[bisdevres]

awesome new feature.

here is some additional functionality we would like to see:

1. be able to see custom properties in the repo about section.
   
2. repo admin can set the property values from this repo about section mentioned above.
3. property values can contain all symbols like !, @, spaces, emojis, ...

[stefanbuck]

I'm working on a browser extension to enable this amongst many other exciting things https://twitter.com/buckstefan/status/1713150817581080589

[AlexandreODelisle]

Would it be possible to consume the repository custom properties to select repository access instead of the drop-down list on a 'Runner Group'

Reference: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups

great feature by the way

[reiniertimmer]

This would be a great win for many other GitHub resources, like actions secrets & vars, apps, etc.. as well.

Right now we run various automation workflows to assemble list of repository IDs (based on topics, for example) and set that specific list on secrets, apps and runner groups. This is a bit inflexible (and causes some delays with availability of these resources)

It would be very nice if we can set such resources by repository property (like setting access to department=X). As soon as a repository department property of X is set on a repository, then that repo would immediately get access to the specific secrets, runner groups, etc.

It would also be much more transparent what the logic behind the repository assignment is (instead of having an endless list of repos on runner groups, you would now simply see department=X - which is much clearer & more maintainable as well)

[chrispat]

Thank you for the feedback.

We are having a number of discussions about where properties could be used across the GitHub experience to improve the ability to manage at scale.

This particular case is not as straight forward as some depending on how you use runner groups.

A consistent point of feedback for properties is a desire for repository admins to be able to edit the values of properties, which is something we intend to implement.

Many customers I have spoken to want to use runner groups as a security boundary which means they typically want someone who manages that runner group to make a determination as to what repositories can use it.

In this case if you had a runner group for department=x any repo admin in the org could give themselves access to that runner group by simply setting the value of their department property to X.

There are some potential ways around this with a more complex permission scheme which is something we will continue to discuss. But it isn't as straight forward as one would hope.

[reiniertimmer]

Thanks @chrispat that is indeed an interesting example.

However, for repository rules (where target by property is implemented) I guess it would be similar. If a rule is applied to repositories by some property, opting in would be just as easy as opting out by repository admins (by overriding a property). Enforcing workflows cannot really be done if repo overrides are possible.

If this is intended to be implemented, it would be interesting if org admins could indicate (per property) if they can be overridden by repo admins or not.

Getting back to the example: if you assign runner groups on a non-overridable property, then repo admins cannot override. If the property can be overwritten, then it would be possible for repo admins to opt in/out on specific features (like a runner group).

I can image some scenarios where this would actually be helpful (for self-service purposes), but of course, each organization is different. I can imagine that having the option to choose override per property would cater to a lot of different cases.

Compared to repository topics, properties seem much more powerful as filtering mechanism. It's so much more transparent (from a user perspective) what repositories are assigned to which resources than what we have now (a list of 1000+ repositories on a runner group is far from transparent).

[speter04]

Hi Team,

I noticed that when I tried to hit the Custom Property API PATCH https://api.github.com/orgs/{org name}/properties/values, I got a 204 status code even though the repo was not present. I believe that if the repo is not present, we should get a 422 Unprocessable Entity status code.

Can someone please look into this and let me know if this is a bug?

[pablonete]

Yep, it's a bug. I've confirmed that any invalid repo names were ignored, so if valid and invalid names were mixed, the 204 meant that the valid names were successfully assigned the values.
A fix is being deployed this morning to correctly abort and return 422 if any repo name is invalid.
Thank you for the report 🙇

[speter04]

@pablonete, thanks for the confirmation. I'm still getting the same 204. Is the fix released globally or yet to ship? Do you have a tentative date for this bug fix?

[pablonete]

@speter04 The fix has been deployed 15 minutes ago

[speter04]

Hi Pablo,

Thanks for notifying me. I have validated the fix and am able to see the 422 response code. :)

[JoaquimXG]

I'm not sure if this is a bug, or just an undocumented change but is anyone running into recent issues with permissions for the /repos/{owner}/{repo}/properties/values endpoint?

It seems at some point between 27th November 17:00 and 28th November 11:00 (UTC) the permissions changed for this endpoint. Previously a GitHub app with repository contents read and repository metadata read could access the endpoint, now the app gets 403 though the permissions have not changed.

It is worth noting the response header 'x-accepted-github-permissions' is now 'repository_custom_properties=read'; I'm not sure if this has changed or not, unfortunately I did not check it before.
I don't think it is currently possible in the GitHub.com GUI to set this permission for a GitHub app. It is also not mentioned in the documentation for permissions required for this endpoint; they still refer to metadata read as the only permissions required.

Just to be sure, I have tested the endpoint with an app that has all the available repository and organisation permissions, read and write or admin where possible.

Some details on the request:

• method: GET
• URL: https://api.github.com/repos/Joaquim-Gomez-Test-Org/test2/properties/values
• headers:
  • 'User-Agent': 'python-requests/2.31.0'
  • 'Accept-Encoding': 'gzip, deflate'
  • 'Accept': 'application/vnd.github+json'
  • 'Connection': 'keep-alive'
  • 'Authorization': 'Bearer [redacted]'
  • 'X-GitHub-Api-Version': '2022-11-28'

And the response:

• status: 403
• body:
  • message: 'Resource not accessible by integration'
  • documentation_url: 'https://docs.github.com/rest/reference/repos#get-all-custom-property-values-for-a-repository'
• headers:
  • 'Server': 'GitHub.com'
  • 'Date': 'Wed, 29 Nov 2023 08:27:02 GMT'
  • 'Content-Type': 'application/json; charset=utf-8'
  • 'X-GitHub-Media-Type': 'github.v3; format=json'
  • 'x-accepted-github-permissions': 'repository_custom_properties=read'
  • 'x-github-api-version-selected': '2022-11-28'
  • 'X-GitHub-Request-Id': 'C3B6:B1D5:17D02142:181BCA4A:6566F5D6'

[liaodaniel]

Yeah, we were getting the same error as well. The required permission scope for our GitHub app was metadata read and that was working prior to the change.

[pablonete]

Thank you for the report! This is correct, there's a bug on the permission check. We're working on a fix.

[JoaquimXG]

Excellent, thank you for the confirmation.

[pablonete]

The fix has been deployed and the required permissions in the repo values endpoint are back to:

x-accepted-github-permissions: metadata=read

[JoaquimXG]

Nice one, thank you. It is working for me now.

[speter04]

Earlier repo admins will be able to see custom properties by going to the URL https://github.com/{org_name}/{repo_name}/settings/custom-properties/, but when I check now, it is throwing a 404 error. Is it a bug or have some changes been made?

[GlebIrovich]

Hey! Thanks for sharing. That was a bug. It must be resolved now.

[speter04]

Thanks now i am able to navigate.

[dvag-dzenan-softic]

Hallo,
If I use this request

await octokit.request('PUT /orgs/{org}/properties/schema/{custom_property_name}', {
                org: Constants.ORG,
                custom_property_name: property_name
                value_type: 'single_select',
                required: false,
                default_value: 'false',
                allowed_values: ['true', 'false']
            })

I get a HTTP 422 Error which says that the Default Value must be empty. Why does this happen? Can I set a default value? In the Docs it is mentioned.

[pablonete]

Default values only apply to required properties, they cannot be used if the definition is required: false.
On the other hand, if you make it required: true, then every repo that didn't set it and every new repo will get the default value, so "required" means that it's guaranteed that there's always a value for the property.

[dvag-dzenan-softic]

Thank you very much :)

[cobavcova]

Why haven't I gotten the new feature preview? Is it only certain people on GitHub who get it? , this is an example of an image that has just been updated on GitHub

[cobavcova]

[dirtygooback]

When should we expect to see that rolled out? I don't have that preview feature on any of my accounts

[cquanu]

Will be good to make this navlist useful like GitHub Advisory Database so that we don't click on something that is not useful.

[nie7321]

Filtering repository by the custom properties doesn't seem to work? This property is a select list and I've defined it on a bunch of repos, but I'm not getting any results:

The filter for this value fails on both the newly-released org repository page, and in the org settings on the screen where I can assign values.

[sbauer]

Thanks for the report! We'll take a look.

[pablonete]

We've identified this issue and deployed a fix for it.

[nie7321]

Working for me now, thanks!

[ljharb]

I'd like to sort by stars, as well as by "used by".

Also it's a bit confusing that i have to select "Forks" to pick "Sources"; it's very non-obvious that i can get to "exclude forks" under "forks".

[ebickle]

Would it be possible to view certain properties in the new organizational repository list alongside topics?

A custom property could have a “show in repository list” setting. When enabled, the property would appear in the organizational repository list alongside topics. In other words, a colored label with the text “key=value” or “key:value” mixed in with the repo topics.

We currently use topics to group our apps and would like to move to exclusively using custom properties. We just need it “visible at a glance” when browsing through our thousands of repositories to get a pulse on what’s happening across the company.

[roeishuster]

Hey,

When creating a ruleset that targets custom properties, no repositories are being scoped for the target.

Is this a known issue?

[chrispat]

Your Ruleset appears to be disabled.

[roeishuster]

It's in evaluation mode but even in evaluation mode I should see that the repo is included in the rulesetisn't it right?

[sbauer]

What state is the repo in? Is it archived? You can reach out to me ( sbauer [at] github.com ) and we can discuss specifics.

[pablonete]

Oh, I think the problem is regarding the missing preview like "targeting N repositories".
I've found out that the preview has been disabled due to an issue and it's being investigated in order to be restored ASAP.
Just to make it clear, it only affects the preview. Enforcing of rulesets is enabled and functioning.

[roeishuster]

ok, that make sense, thanks for clarifying this :)

[cobavcova]

Old code search, can it be restored, someone please reply

[dvag-dzenan-softic]

Hello everyone,

i know the custom properties can be accessed via the REST API. Is it possible to access them via the GraphQL API?

Thank you!

[dvag-dzenan-softic]

Hello,
I have a problem with the github.event.repository.custom_properties.xxx within workflows which use the schedule trigger. The event context seems to be empty, while in manually triggered workflow they have the expected value. Is this expected behaviour or a bug? The workflow is the same one.

[ebickle]

Would it be possible to add an option in the (beta) repository filter list to allow repository properties that are blank to be selected?

A common use case for us is to list repositories missing a value.

[pablonete]

Thank you for the suggestion.
The current way to accomplish it is using a negative filter with all known values like: -props.platform:iOS,Android