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.

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

[jeffolen4]

@chrispat Any update?

[chrispat]

You can enable the feature preview for the list now https://github.blog/changelog/2023-12-06-new-organization-repositories-list-feature-preview/

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

[dzenansoftic]

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

[ebickle]

We have over 200 different property values, so sadly not an option for us in the long term. 😁

[pablonete]

@ebickle Since today, we're testing a new syntax to filter repos without a value like props.platform:none
It can also be negated to find repos that got a value: -props.platform:none
We're evaluating it, so there's no guarantee that it will be kept in the product.
Any feedback we receive will be helpful.

[ebickle]

@pablonete Seems like a good idea to me! Simple and straightforward

[vivekanandg]

Can we filter by a regex? eg: props.key: val.*

[ebickle]

I think I might have asked this before (apologies if this is a duplicate!).

The company I work for needs the ability to preserve properties when a repository is transferred between two organizations in the same enterprise. I understand my there would be issues transferring between two independent orgs due to trust and privacy issues, but that isn't an issue within an enterprise.

We're using custom properties to track security-relevant information such as "in scope for PCI compliance". We also have teams that occasionally ask for their repositories to be transferred between orgs for valid other reasons. Preserving the properties is critical so that we can continue tracking the security characteristics of those repositories/applications even after they are moved.

We looked at possible workaround on our side, but because repository transfers are a two step process there's no clear solution. Seems like a gap in the GitHub implementation at the moment.

[ghost]

Hey, I think i found a small bug.

When you are in an org repo page (Mozilla's for example - https://github.com/orgs/mozilla/repositories), toggle one of the following to a non-default value:

When you toggle it back, the param question mark is still present:

(Using the latest version of Firefox on Windows 11)

[htekdev]

I would like to see property types have some modified scope. Meaning, that org admins and repo admins should control some properties vs others.

We are seeing that the lack of the ability for repo admins to make changes prevents us from leaning on custom properties for informational things.. We have had to make a full framework to enable our developers but I do see potential to make custom properties even better by expanding how properties are managed.

[pablonete]

Thank you for our feedback.

There's a property definition setting named "Allow repository actors to set this property" that allows those properties to be modified by repo-admins, and these permissions can be tailored down by using fine-grain permissions. Does it fit your use case?

[shaedrich]

It would be even better if that was the default so that custom properties could be used in repositories that don't belong to an organisation in the first place.

[htekdev]

Yes. Actually, this works perfectly!!

[grandmas-favorite]

Hi @yehiamitro111 , thanks for participating!

We take our Code of Conduct very seriously and want to help ensure that everyone has a good experience free of antagonism and harassment. Unfortunately, we don’t currently have moderators for languages other than English. Until that changes, we need to ask that everyone use English here in the GitHub Community when posting. We’ll be hiding any posts in languages other than English for now, including this one.

[Waterstraal]

Would love to be able to get a "Group by" in the repository view, where you can group by a Custom property. Similar to what's possible in Projects.

[Leestex]

It would be great to have an additional type of custom property - user.
This will allow us to add properties like "Owner" or "Lead", in the case when each repository has a single repository lead.

[raihle]

Any chance of including custom properties in the "list repository" REST endpoints, similar to the workflow context?

[raihle]

Even if the property itself is not included in the response, I would expect the "updated_at" timestamps in the "list repository" response (or something analogous) to change when a custom property value is updated in that repository.

[jeffwilcox]

Agree that would be nice. In the past I've found that a number of items reflected in the 'get repository' response do not trigger any changes to the 'updated_at', though. Things like configuring security settings, wikis, etc.

[kc8se]

Any chance of GraphQL support? Pretty please.

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

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

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

[kydyrmyshov107]

Response #2