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.

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

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

[dzenansoftic]

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!

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

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

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

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

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

[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

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

[kc8se]

Any chance of GraphQL support? Pretty please.

[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

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

[shaedrich]

Who can use this feature

Organization owners can add and set a custom property schema at the organization level. People with read permissions to a repository can view the values of custom properties for that repository.

Is there a reason why this is limited to organizations?

I'm asking because I'd like to use them, but I'm not part of an organization where this would make sense, even though I have repositories not associated with any organization where I would use them.

[pablonete]

Can you elaborate more on your use case? What value would properties provide to you used outside an org? Where would you define them?
Currently there are no plans in this regard, but we're always happy to hear your thoughts.

[shaedrich]

It's funny: I always wondered what value they had exclusively inside an org, and what the problem was with not extending them to repositories. I actually can't see a huge difference there.
I mean, no matter if they are inside an org or not, people want to categorize their repositories with key-value pairs, which currently isn't possible when the repository isn't part of an org.

[chrispat]

One of the challenges with repository level properties is simply maintaining the uniqueness of the property schema. If, for example, you could define properties exclusively at the repository level and two repositories defined the same property name but had different ideas about what those values should mean you then have to disambiguate that is search somehow. There are other challenges with visibility, users have access to different repositories and if each repository could define different sets of properties the system would need a way in search to only show you the property keys and values from repositories where you have access. Both of these would create significant challenges that can of course be overcome; however, we have chosen to prioritize other areas to invest that time.

[shaedrich]

Ah, okay, yeah, from a technical standpoint, this makes total sense. Maybe, there could be different types of properties:

• global (like actions-only)
• local (with prefix of the user/org like (like github.actions-only or user:github.actions-only or the like)

[chrispat]

Yes, there are possible solutions but for now our goal is to bring properties to enterprises as a next step.

[mbridard]

This new custom properties feature is really nice, as organization owner would it be possible to choose if a property can be edited by a repository admin/maintainer.

We would like to use the custom properties and rely on a repo admin/maintaniner to specify for example:

• the nature of the repository (is it production code, is it training material, etc...)
• type of code (is it frontend, backend, etc..)

We have strong need of putting governance in place and providing a list of predefined value per property is what we are looking for.
Would it be also possible to set these available property at Enterprise level so that all organization -> repositories have some mandatory property to fill?

Thanks

[ebickle]

Agree on both points. We have certain properties that we'd like repository (team) admins to have the ability to modify. Not all, but some.

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

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

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

[ebickle]

Are properties preserved when transferring repositories within an enterprise, provided a property with the same name and data type exists in that target organization?

[chrispat]

No, they are not. Each property is unique in an org even if it has the same name.

[roeishuster]

Hey,

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

Is this a known issue?

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

[charles-poullet-unmind]

Hi @pablonete
Do you know when the preview will be enabled?

[cobavcova]

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

[philpennock]

This is great to see and is set to relieve one of my major audit pain-points, so first and most importantly: thank you!

1. At present, these properties are public. Any chance we can have visibility restricted to those with Write or Maintain levels of access? We have public open source repos in our organization which we'd still like to be able to tag with private audit properties, and part of that includes some information which might be staff PII, so we'd rather not do this in public
2. It would be good to be able to set a custom property as "required for all new repos" without requiring a default value for existing repos
3. It would be good to have an email address type, and to be able to auto-populate a default on edit or new repo creation of "one of the email addresses in the user's account, filtered to being in a verified domain for this organization" (or just "to a specified domain on the property")
   • This isn't the same as the audit log of who created the repo, as the creator should be able to specify an arbitrary email address here, of a team or of a colleague, but having a default of their own will do more to nudge them to Find Another Victim than a blank default. :)

Thanks again.

[jeffwilcox]

When you say "public", what do you mean? If you sign out of your GitHub account, or use a private browser window, you will not see the custom properties. However, the properties are visible to your organization members who have administrative access to a repository... so "internal" might be a better word than "public"?

[philpennock]

This doesn't appear to be true? Eg, for the repo ConnectEverything/client-tools I can curl https://api.github.com/repos/ConnectEverything/client-tools/properties/values without a PAT and see the properties. This appears to be public, for public repos.

[jeffwilcox]

Wowwwee yeah.... I was not expecting that!

[philpennock]

I should have done this as a security report then and asked for $$ for the Pittsburgh Community Foodbank. 😆

[chrispat]

At the moment this is by design. One of the key pieces of feedback we have had from customers is using properties in Actions workflows and doing that means they need to be in the various webhook payloads that trigger those workflows. Once you do that it makes it essentially impossible to hide data from anyone who can cause a workflow to be triggered. In the case of public repositories anyone who can open a PR can cause a workflow to be triggered.

We are looking at options for marking some properties as confidential or secret and what that would mean across the various experiences where we plan to expose properties.

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

[Jesson1018]

It seems that currently we can modify custom properties by calling API in a batch. Is that possible that an user can modify custom properties by GUI? That will make things easier as I expected. Thanks.

[jeffwilcox]

Organization owners can modify and edit properties in the interface.

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

[jeffwilcox]

On the minor feedback side, the repository-level user interface for custom properties that is shown to users includes a link to the org-level custom properties experience, making an assumption that they may be an org owner.

As a non-org owner, I then get a 404 when browsing to the link.

Screenshot of the area I am referring to, for example, while at https://github.com/contosoenterprise/onboarding/settings/custom-properties, the link goes to https://github.com/organizations/contosoenterprise/settings/custom-properties, a 404 for me as a non-owner.

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

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