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?

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

[rpgeddam]

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

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

[ArminPrieschl]

It would be nice to use this properties for the Copilot Content Exclusion Filter.
Are there any plans for this?

THX

[rodelta]

It would be fantastic to be able to display these props in the about page, as a way to communicate common organization data across teams. I imagine the visibility could be set at organization or repo level.
It's useful to set up things like a responsible team without forcing people to go look at "custom properties".

[ahacke]

I would like to be able to see the custom properties also on the default organization view where the repositories are listed.

Ideas are:

• Make the option in general configurable on org level
• Make the custom properties to show on the organization view configurable: I expect, that there could be a lot and the view can get cluttered easily unless it is filtered, configured
  • This could also be interesting for the repository list view
• Best case, the visible custom properties at repositories can be sorted and ordered

[atuj01]

will this custom properties be included in the graphql schema ?
(somewhere and repo/node level, something like: custom_properties)

[uncenter]

Would really love this! Surprised it is only offered in the REST API as of yet.

[uncenter]

FYI @atuj01 I've opened a separate discussion for this topic: /~https://github.com/orgs/community/discussions/126852.

[philthethrill99]

Will the repo custom properties will be added to the team.added_to_repository and team.removed_from_repository webhook event payload?

They are already in the member.added and member.removed

[jchuerva]

Yep, it's a bug. I've confirmed that we are not sending it. We are working on a fix.

Thank you for the report 🙇

[jchuerva]

The fix has shipped and you should see the custom properties in the team webhook events.

[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