Add custom properties

[Sandijigs]

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

[rustbot]

rust_team_data/src/v1.rs has been modified, it is used (as a git dependency) by multiple sub-projects like triagebot, the www.rust-lang.org website and others.

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 rust_team_data crate.

[github-actions]

Dry-run check results

[WARN  rust_team::sync] sync-team is running in dry mode, no changes will be applied.
[INFO  rust_team::sync] synchronizing crates-io
[INFO  rust_team::sync] synchronizing github

[ubiratansoares]

@Sandijigs thanks for this PR, looks we are in the right direction here. Added a few comments :)

[Kobzol]

Left a few comments :)

[Kobzol]

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

[Sandijigs]

Removed. Makes sense given the generator updates before consumers.

[Kobzol]

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.

[ubiratansoares]

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.

[Kobzol]

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.

[ubiratansoares]

I'll check whether there are any custom properties out there, so we don't break anything by mistake here

[Sandijigs]

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.

[ubiratansoares]

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)

[Kobzol]

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

[ubiratansoares]

@Sandijigs looks good to me, one small thing from my end

[ubiratansoares]

@Sandijigs Some additional considerations after trying out custom properties in a org/repo I own.

[ubiratansoares]

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

[Sandijigs]

for this I kept as Option for now and updated the schema docs to note only text-type properties are supported.

team/docs/toml-schema.md

Line 558 in dc12bfb

Values are stored as strings. Only text-type custom properties are supported for now.

[ubiratansoares]

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

[Sandijigs]

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.

team/src/sync/github/mod.rs

Lines 927 to 935 in dc12bfb

	if !org_property_names.contains(name) {
	diffs.push(CustomPropertyDiff {
	name: name.clone(),
	operation: CustomPropertyDiffOperation::CannotApply {
	reason: format!("'{name}' is not defined at the org level"),
	},
	});
	continue;
	}

[marcoieni]

Suggested change

	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

[marcoieni]

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.

[marcoieni]

I created the custom property for the rust-lang org

[Sandijigs]

I created the custom property for the rust-lang org

Thanks for pushing this through. I've pulled the changes locally and tests pass. Reading through the diff now to make sure I understand the design.

[marcoieni]

I think this is ready to be merged. Can you reorganize your commits in a way that you like? If you prefer, I can squash them into a single one, too.

[Sandijigs]

Great, I will squash all commits into a single one

[rustbot]

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.

[Sandijigs]

It has been squashed to a single commit. Ready to merge.

[marcoieni]

apparently github api doesn't support booleans for custom properties 😅 I will make some changes quickly, then try to merge again.

[marcoieni]

https://github.com/rust-lang/crabwatch/custom-properties 🥳