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.

[ArminPrieschl]

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

THX

[ArminPrieschl]

Will this feature be moved to Github Enterprise Server?

THX

[raihle]

According to the roadmap, it is planned for the next release (3.13): https://github.com/orgs/github/projects/4247?pane=issue&itemId=32913635

[Taucher2003]

The space on the custom properties page is poorly used. It seems to favour long property names instead of long values which makes it quite useless for "project details".

For example, if you want to link to somewhere (for example, where CI runs), the URL gets cut off and there is a lot of wasted space that could have been used to show the full value.

[raihle]

Some of the uses we previously had for topics make a lot of sense as custom properties. But there is one downside: anyone with read access can see topics, but only admins (maybe maintainers as well?) can see custom properties in the UI. Could custom properties be exposed in a similar way to topics? Perhaps with a per-property setting.

[ebickle]

Our users have made the same request multiple times. Right now we still use topics and then have a custom developed GitHub application to synchronize the topics over to custom properties - all so that we can see the information at a glance in the repository list page and the repository overview page.

Our request is exactly the same - a repository property setting that causes property values to show up alongside topics in a similar manner. E.g. in the repository list or individual repository overview page where the topics are currently shown: "(topic1) (topic2) (property_name:property_value)".

[chrispat]

Anyone with read access should be able to see https://github.com/<org>/<repo>/custom-properties.

[raihle]

@chrispat Oh, yes - and I see there's a link in the "About" section. A little more visibility would be nice but I will forward this :)

[Simon-Boyer]

When modifying a repository using the API, there is no way to modify the custom_properties attribute even if you can set that attribute at repo creation: https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#update-a-repository. Is there a plan to add that capability in the following weeks? I would need this very soon.

[raihle]

It's less convenient, but could you use https://docs.github.com/en/rest/repos/custom-properties?apiVersion=2022-11-28#create-or-update-custom-property-values-for-a-repository?

[Simon-Boyer]

The thing is we are using Safe-Settings to manage our repos. Since Safe-Settings is using the repository API directly, it currently will create a repo with custom properties when they are configured in the yaml file, but it will not update or delete them afterwards.

I could open a PR to add this specific use case handling, but it's not really pretty to do that and if there is a plan to add this to the API soon it's probably not worth it. That is why I was wondering what is the plan for this, since it is in the repo api for creation, I assumed there was some plan to add this to the PATCH request too or am I wrong?

[Simon-Boyer]

@chrispat Is there any plans for this ^ ? Our client needs this and if its not in the plans I'll need to open a PR to add support explicitly to Safe-Settings. I just need to know to organize my time.

[chrispat]

This is not something we are changing at this time.

[ebickle]

The List custom property values for organization repositories REST API isn't returning property values for all repositories.

I noticed that some of our archived repositories aren't returning any property values in that API call. There's no documentation to suggest archived repositories are omitted (it just states "Lists organization repositories") and anecdotally it seems as though some repositories have values returned, while others do not.

API calls are being made via Octokit: await octokit.paginate(octokit.rest.orgs.listCustomPropertiesValuesForRepos, { org, per_page: 100});

I then made a call to octokit.rest.repos.get() with one of the repositories missing from the listCustomPropertiesValuesForRepos response and I can see the custom properties are there.

Any ideas? Should I file a support ticket?

[ebickle]

Additional info:

• Only archived repositories are affected
• Most archived repositories do not have any properties returned, but one was. The one that was returned had a property value of null.

[vaindil]

A fix was pushed for this a couple weeks ago but wires were crossed and we didn't follow up, sorry about that! This should now be working correctly.

[aryejfa]

Response #20457

[haagenson]

What does the roadmap look like for custom properties?

We are interested in array values for properties so that we can track monorepos that would have multiple valid values for some properties.

[pablonete]

Stay tuned, multi_select properties are in the oven cc @chrispat

[djs-intel]

In my case we will be keeping arrays of values in a similar manner but values are expected to widely vary with new values being created daily, making selection not an option. Format may be integers or strings with a comma delimiter. Would it be possible to define pattern matching rules for these types of use cases?

[taiki45]

I suggest integrating custom properties with the gh repo list command, similar to repository topics. Specifically, include custom properties in the output when using the --json option. This would make managing and filtering repositories based on custom properties easier.

We've been managing repository metadata with repository topics. Then we moved to custom props from topics but we need keep sync from custom props to topics for some cases.

[kydyrmyshov107]

Response #2

[ebickle]

One thing that would be a huge help for my company is custom properties that can be set as “required” but without a default value.

Required properties without a default would work like this:

• Existing repositories without a value would be treated the same as any other missing property. (Blank/undefined)
• Users creating a repository via the GitHub UI would be required to select or enter a value.
• Creating a repository via API would fail if the custom property isn’t set at the same time.

[chrispat]

This is something we are looking at but need to address how we will enable users who are not org admins to set properties while creating a repo. At the moment to set all properties you either have to be an org admin or have the permissions to manage property values across the entire org or be a repo admin which enables you to manage properties that have been delegated.

Due to these constraints, we initially required the default value so repos created by users without the necessary permissions could still create them rather than being blocked by a required property they can't manage.

We have had a few discussions about that on the team and we can enable users who are creating repositories to set the value properties that are delegated to be managed by repo admins as users who create a repo are set as the owner for the repo they create.

[Taucher2003]

When will https://api.github.com/search/repositories support filtering by custom properties?

When using a query like props.something=something it complains that searching by custom properties is only available when an organization is specified, but if I use a query like props.something=something org:something, it silently ignores the filter for custom properties and returns all repositories from the organization.

The same query does work on https://github.com/search?type=repositories

[jchuerva]

It seems that the functionality is working well.

In the search feature, if the user lacks access to the organization, we ignore the props.something=something parameter. This requires the user to be logged in; otherwise, both the UI and API will disregard the custom properties.

Indeed, in the UI, when searching within a public organization without being logged in, the custom properties aren't suggested and ignore them for searching.

[Taucher2003]

@jchuerva I just tested it with a personal access token and that does indeed work. Now the question is what permission a GitHub App needs to use this filter. The app I'm using has read/write on custom properties for both the repository and organization permissions (and some other additional permissions that don't look connected to custom properties).

[pablonete]

The app needs the organization_custom_properties permission.
There's been a recent bugfix related with this, can you try it again and let us know?

[Taucher2003]

@pablonete thanks for letting me know. It does work now without any changes to the permissions of the app 👍

[neilprosser]

Should we be able to use the props.NAME:VALUE syntax when searching in the search box on https://github.com/orgs/ORG/security/coverage? It doesn't appear to be working for me (though that may very well be a problem between the seat and the keyboard).

It would be great to be able to do this so I can batch edit the security settings of repositories with a particular property value.

[chrispat]

The security alerts team is working on including properties in their search functionality. I am not sure exactly when that will ship but it is coming soon.

[kc8se]

Any chance of GraphQL support? Pretty please.

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

[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

[Utsav2]

Is this available on all GitHub plans?

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

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

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

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

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

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

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

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

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

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

[lucien-heart]

Wonderful!

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