Repository Custom Properties Feedback

[chrispat]

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

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?

[rpgeddam]

@djonser @chrispat Is there a public roadmap issue I could track for inclusion of custom properties in OIDC claims?

[tofay]

That would be really useful. I want to use a custom property to apply a branch protection rule to a large subset of repositories in an org. I then want to restrict an OIDC claim to the protected branches of repositories with this customer property.

[dylanmei]

This is a game changer idea for managing large number of repositories that need access to various cloud services via OIDC.

[aron-muon]

100% agreed that this would be a game changer. Otherwise, lots of hacky and fragile workarounds are needed on our end.

[beatngu13]

This seems to be possible now:

GitHub Actions OpenID Connect (OIDC) tokens now support repository custom properties as claims. Additionally, a new settings page is available in public preview, making it easy to configure OIDC token claims directly from your repository, organization, or enterprise settings while adding properties to the claim.

https://github.blog/changelog/2026-03-12-actions-oidc-tokens-now-support-repository-custom-properties/

[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?

[zubozrout]

Is that option still there? I don't have it in the Feature preview dialogue nor do I have these filtering options on the repositories listing page. We are looking into categorizing repositories and this new feature is something that looks useful for that, but unfortunately atm it seems unavailable. Thank you :)

[pablonete]

The option was removed because it's enabled for all users.

[zubozrout]

Thank you @pablonete. That is what I thought could be the case, but I don't have it and neither does anyone else in our team:

Based on the screenshot from the page you linked there should be a filter next to the search field, yet I don't see any. We were already able to set Custom Properties to our repos (the few we currently have in), but filtering by that seems to be impossible on our end.

[pablonete]

You can start typing prop to get suggestions for the available custom properties, like:

There's a new UI in the oven intended to improve discoverability 😉

[zubozrout]

I missed that. Thank you very much @pablonete :)

[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.

[reiniertimmer]

@chrispat sorry to revive such an old comment, but I found out that it is in most of the payloads in GitHub Actions, but for some reason, it's missing on the schedule trigger.

I've tested this with a workflow that runs both on workflow_dispatch and on schedule.

When running on workflow_dispatch, the github context contains .event.repository with custom properties. However, for schedule, the same event.repository context is available, but without the custom properties.

I ran a JSON diff on the event.repository object, and custom_properties is the only field that is different. Is there any particular reason for this, or is this just an oversight?

[jchuerva]

Yep @reiniertimmer , it's a bug. I've confirmed that we are not sending it for schedule workflows. A fix is currently in progress to address this issue.

Thank you for the report 🙇

[reiniertimmer]

Thanks for the confirmation @jchuerva!

[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.

[weilinzung]

We have same issue of it

[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).

[jgrumboe]

Is there any progress in using custom properties as targets for more things than rulesets? Like mentioned Actions Secrets & Variables would be awesome!

[AlexandreODelisle]

Do we know when the custom properties will be more integrated in GitHub Actions? A few concrete examples.

• Runner Group definition (instead of managing a list of repositories)
• Custom Claims Ref for OIDC (workload identity)

[dserodio]

The link to the documentation in today's blog announcement is broken, it links to the docs for rulesets.

[atuj01]

the repo updatedat date (from graphql) is not modified when we are setting a custom property value - meanwhile when we are setting a topic for a repo, the date is updated, is this a bug or planned or a missing functionality ?

[dzenansoftic]

Hello, we discovered today that there is a limit of entries for the single select custom property type of 200. First of all it would be nice to see that there is such a limit when creating a custom property of that type. Second thing is we stored some valuable information in a single select custom property, but we cant use it anymore because of the limit. Are there any plans to upscale that limit for something like 1000 entries or similiar?

[raihle]

We have a case that's likely similar to yours. Another option for us would be to provide a validation service that GitHub calls before a value can be saved (using a similar approach for autocompletion would be nice too).

[akinnane]

The 200 entry limit is a problem for us too.

[ebickle]

+1

We have structured application codes that we require all repositories to be tagged with. There are over 200 of them, so the limit is a blocker. A free text field allows people to enter invalid values.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[akinnane]

We are having an issue where single_select values containing a hypen - are not allowed by a validation rule. Seems like a very weird constraint on the values when they are defined as an array of strings. Could this validation entry be removed and a full list of the validation rules published?

[GlebIrovich]

Hey! Thanks for reaching out. You can find the list of allowed characters here. We do support hyphen for both names and single select options.
Could you share a value you are trying to create?
Do you use properties UI or API?

[akinnane]

Thanks for the reply @GlebIrovich.

We are using the PUT /orgs/{org}/properties/schema/{custom_property_name} API from https://docs.github.com/en/rest/orgs/custom-properties?apiVersion=2022-11-28#create-or-update-a-custom-property-for-an-organization

The error message we receive is
http status code: 422
message: "Validation failed: Allowed values 'Digital Delivery – OIG (Protected)' contains invalid characters: –"

We are using the same API to create other custom properties and it works correctly for those.

[akinnane]

Actually, it looks like the offending character is U+2013 : EN DASH. Do you plan to support unicode characters in tag values? How would you deal with languages that require unicode?

[GlebIrovich]

Thanks for sharing. As mentioned in the docs, rn we focus on supporting ASCII chars only. I will forward your question to our product team.

[dzenansoftic]

Hello, we manage our custom properties mainly over the API, so we update, delete and add properties. For one property where we use the single_select type, we cant delete custom properties from the list because they are in use. I checked the repositories which uses those properties and it turns out the repositories are all archived. It would be nice if the properties which are only "used" in archived repos could be deleted.

[jasontempleman-eaton]

I need to get a list of all repositories in an organization that have a specific custom property. Would love to do this trough an API call but that doesn't seem to be currently supported. Is this something that is in queue to be add or could a request be entered for this functionality.

[jchuerva]

👋 @jasontempleman-eaton. This option is available in the Search repositories endpoint. See the search-based-on-repository-custom-property doc.

[steinybot]

I'm surprised that the repository object in the webhook events contain the custom properties but the REST API repository objects do not. Is this an oversight?

I have a GitHub App that listens for repository and custom_property_value events and will then list all our repositories and get the value of the Group property for each one. It then updates our organization's profile to list each repository under a collapsible section for each group. This is a pretty nice workaround for having no ability to group repositories. The bad part is that this requires about 507 requests (5 to list all the repositories, 500 to get the custom property for each repository, 1 to get the profile contents, and 1 to update the profile contents). Ideally, I could use the GraphQL API and do this whole thing in only 3 requests. Not quite as good but the list-organization-repositories REST API included the custom properties then it would be 7 requests. That's a 98.6% saving.

[steinybot]

I figured I should probably raise a separate discussion for this: https://github.com/orgs/community/discussions/152576

[raihle]

I agree with your request, but FYI there is an endpoint that lists custom properties for an org (which should get you down to 10 requests) : https://docs.github.com/en/rest/orgs/custom-properties?apiVersion=2022-11-28#get-all-custom-properties-for-an-organization

[mattzuba]

@raihle - that REST endpoint does not get the property values on repositories, only what properties are defined in the organization.

[raihle]

@mattzuba You're right, sorry. The proper endpoint is https://docs.github.com/en/rest/orgs/custom-properties?apiVersion=2022-11-28#list-custom-property-values-for-organization-repositories

[akinnane]

There really needs to be a way to validate the value of a free text field, or the limit for the number of selections needs to be dramatically raised. We are currently seeing lots of people enter invalid values which defeats the point of our use of custom properties.

[patrick-knight]

We just added support for regex validation on the text field

[akinnane]

Thanks, but this totally misses the mark of what we need to do.

We are only using the free text field to work around the 200 item limit discussed above. I've checked the API docs and this validation parameter doesn't appear in them at all, but I guess I can't use to stuff 300 values into a validation regex. Can't you just bump the limit up from 200 to 300/400/more?

https://github.com/orgs/community/discussions/69914#discussioncomment-9903462
https://docs.github.com/en/rest/orgs/custom-properties?apiVersion=2022-11-28

[rober15]

Is there a way to define customer properties on enterprise Organization Level but allow them to being changed not only by organization admins but as well by the repository admins ?

[weilinzung]

Hello from the properties team! Yep, you can do that. When creating or editing the property definition toggle Allow repository actors to set this property checkbox. This will delegate setting property values by the actors with repo level permissions

Is this the solution for this? https://github.com/orgs/community/discussions/69914#discussioncomment-7318685

[GlebIrovich]

Hi @weilinzung! Thanks for reaching out.
Custom properties are a security feature, so we take a very conservative approach to value edit permissions.
Values for properties assigned to repo actors can be set by repository admins. If you’re on the GitHub Enterprise plan, you can also create a custom role to have more granular control over which users can set property values.

[weilinzung]

Hi @GlebIrovich,

From our perspective, the current custom properties feature isn’t very easy for all levels of users in a big organization to work with. What we’re really hoping for is something much simpler:

• a basic input field that every user can fill in when creating a new repository, and later update if needed — without requiring admin-level permissions or custom roles.
• The goal is less about enforcing security policies and more about improving organization and consistency.

A lightweight “category” field (or similar metadata input) that all users can set during repo creation would solve our use case perfectly, without needing to delegate elevated permissions.

Would love to see this feature can evolve to a more user-friendly option for our usage.

[GlebIrovich]

Hey! Appreciate your input! I’ll pass it along to the team.

[GlebIrovich]

Hey @weilinzung, I am trying to understand your use-case a bit better.

a basic input field that every user can fill in when creating a new repository, and later update if needed — without requiring admin-level permissions or custom roles.

When Allow repository actors to set this property is enabled, the user who creates the repo can set this value, because in that case user is a repo admin. This also means that same user can update the property later on (as long as delegation is enabeld).

So I think delegation covers the creation scenario. Could you confirm?

Now about the update, as far as I can see from other threads if seems like you would like repo maintainers to set property values as well. Correct? Is it the setup you are missing?

[chase-roohms-solarwinds]

It would be fantastic if we could filter on custom properties at the enterprise level under the security tab https://github.com/enterprises/<ENTERPRISE>/security/overview the same way we can filter on them at the organization level. Any plans to implement that in the future?

[jsoref]

• custom properties needs love #192148

[Owen-WatkinsSystems]

Hey, it's a simple one but can we get better searching functionality when filtering on custom properties?

Right now under the repositories of an org, I can search like:
props.<PROPERTY_NAME>:<EXACT_PROPERTY_VALUE>

But I'd love to be able to search with wildcards so I could get away with
props.<PROPERTY_NAME>:*<PART_OF_VALUE>*

Where I've got a property which has a longer value that is unique with some memorable part (e.g CompanyRegisteredName:"Github Software UK LTD."), I don't have the exact company name memorised, but know the general name, but I still have to go to a repository that I know has the value I want, copy the value out of it to then go back to the search page and put in the property for the search, where as if I could just search CompanyRegisteredName:"Github*" would make it 10x easier.

Almost seems like something that should already be there, but from a brief play around and search online, I can't find it documented anywhere. Here is the closest I got to https://github.com/github/docs/blob/main/content/search-github/searching-on-github/searching-for-repositories.md

Going a step even further, it'd be nice to have options appear when you key in a custom property, so if you've got 5 potential different values, you're shown a dropdown list with the 5 values you could select.

Just small QOL changes that'd help.