Add custom properties#2512
Conversation
|
If you are changing the data structures, please make sure that the changes are not going to break serde deserialization (adding a field is fine; removing or renaming a field isn't). If you must do a breaking change to the format, make sure to coordinate it with all the users of the |
Dry-run check results |
ubiratansoares
left a comment
There was a problem hiding this comment.
@Sandijigs thanks for this PR, looks we are in the right direction here. Added a few comments :)
| // Is the GitHub "Auto-merge" option enabled? | ||
| // https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request | ||
| pub auto_merge_enabled: bool, | ||
| #[serde(default)] |
There was a problem hiding this comment.
The #[serde(default)] annotation is not necessary, because the generator (the team API CI) will be updated sooner than the consumers (the crates that depend on the team crate).
There was a problem hiding this comment.
Removed. Makes sense given the generator updates before consumers.
| #[derive(Debug)] | ||
| enum CustomPropertyDiffOperation { | ||
| Create(String), | ||
| Update(String, String), // old, new |
There was a problem hiding this comment.
This should perhaps also contain Delete, in case the custom property is removed from the team config.
It would mean that team is the ground truth for all our custom properties, although it would also delete all custom properties that are not set in team.
@ubiratansoares Do you want team to be the ground truth for all custom properties? If it is not, then once a property is created through team, it won't ever be deleted again.
There was a problem hiding this comment.
Do you want team to be the ground truth for all custom properties?
That's an interesting question, my gut feeling says yes, since I see these custom properties as tool to enable governance-related automations over Github repos or Github orgs, and team is the place where we want represent and enable such stuff with IaC.
There was a problem hiding this comment.
I agree, but we should be then careful with the first sync (or ideally a dry-run executed manually) to ensure that we don't delete any existing custom properties; those would have to be backported into team first.
There was a problem hiding this comment.
I'll check whether there are any custom properties out there, so we don't break anything by mistake here
There was a problem hiding this comment.
Added the Delete variant. The diff emits a. Delete for any property on GitHub that isn't declared in TOML, so team becomes the source of truth. The apply sends a null value through the existing PATCH endpoint, which is GitHub's way of unsetting.
There was a problem hiding this comment.
I'll check whether there are any custom properties out there, so we don't break anything by mistake
@Sandijigs @Kobzol just to confirm : I ran a custom script and confirmed that no repos actually use custom properties (for rust-lang org)
There was a problem hiding this comment.
Ok, good to know. In that case we can directly switch to using team as a source of truth (unless repos in some of our other orgs use them.. :) ).
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
2a53766 to
ef1724a
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ubiratansoares
left a comment
There was a problem hiding this comment.
@Sandijigs looks good to me, one small thing from my end
3dfeadd to
a9b0499
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ubiratansoares
left a comment
There was a problem hiding this comment.
@Sandijigs Some additional considerations after trying out custom properties in a org/repo I own.
| #[derive(Clone, Debug, PartialEq, Eq, serde::Serialize, serde::Deserialize)] | ||
| pub(crate) struct CustomPropertyValue { | ||
| pub(crate) property_name: String, | ||
| pub(crate) value: Option<String>, |
There was a problem hiding this comment.
Right now we are modelling propertie values as optional string fields, but actually what we get here in the API response will depend on specifics of custom property settings:
As an example, when we set the property type as multi-select we'll get an array of strings in the API response. Tested with one my repos:
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2026-03-10" \
/repos/dotanuki-labs/testbed/properties/values
[
{
"property_name": "Category",
"value": [
"DevOps"
]
}
]
Perhaps we don't need to support all types of custom properties to get started, but we must clarify that we support only text-field like properties for now
There was a problem hiding this comment.
for this I kept as Option for now and updated the schema docs to note only text-type properties are supported.
Line 558 in dc12bfb
| if !self.dry_run { | ||
| // REST API: PATCH /repos/{owner}/{repo}/properties/values |
There was a problem hiding this comment.
Since custom properties must be pre-defined at org-level to be applied, I think we should capture whether we are able to apply the custom property in the dry-run
There was a problem hiding this comment.
Added the check. When a TOML property isn't defined at the org level, the diff emits a CannotApply operation and the apply step skips the API call.
Lines 927 to 935 in dc12bfb
a9b0499 to
40e3c1c
Compare
This comment has been minimized.
This comment has been minimized.
e446f66 to
dc12bfb
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
| crabwatch = "true" | ||
| ``` | ||
|
|
||
| Properties set on GitHub but not declared here are left unchanged. |
There was a problem hiding this comment.
So how do I delete a value that I set here before? Manually?
I expect that if I delete the value from the toml file, the team repo deletes that.
Don't worry about retro compatibility. We can write all existing values in the team repo before merging this.
| Properties set on GitHub but not declared here are left unchanged. | |
| Properties set on GitHub but not declared here are removed. |
Maybe this is a more correct statement of the behavior of this PR?
|
|
||
| [Repository custom properties] are values set on a repository to opt it into org-wide tooling. The property must first be defined at the organization level. | ||
|
|
||
| Values are stored as strings. Only text-type custom properties are supported for now. |
There was a problem hiding this comment.
| Values are stored as strings. Only text-type custom properties are supported for now. | |
| Only text-type custom properties are supported for now. |
Remove redundant implementation detail
|
|
||
| ### Repository custom properties | ||
|
|
||
| [Repository custom properties] are values set on a repository to opt it into org-wide tooling. The property must first be defined at the organization level. |
There was a problem hiding this comment.
| [Repository custom properties] are values set on a repository to opt it into org-wide tooling. The property must first be defined at the organization level. | |
| [Repository custom properties] are values set on a repository to add metadata. For example, they are used to opt it into org-wide tooling. The property must first be defined at the organization level by an infrastructure admin. |
- specify that custom properties can also be used for other things
- Make clear that a contributor can't do it. So that they know who to ask in case they want a new property.
|
we should at least support also booleans additionally to strings, so that we can define the crabwatch label as a boolean from the beginning, so that we don't have to do migrations later. Supporting only booleans is also ok. I can work on this if you want. EDIT: I asked gpt 5.5 to implement it and it looks good. I committed these changes. |

Adds support for
[custom-properties]in the team repo's TOML, and setscrabwatch = trueon rust-lang/crabwatch.Booleans only for now. Properties on a repo but not declared in TOML are left alone.
Closes #2504.