Add CustomProperties to default GraphQL property lists for all Get-GitHubRepository paths

[MariusStorhaug]

Context

When using Get-GitHubRepository in automation — for example to audit custom property values across all repositories in an organization — the output includes custom properties for some code paths but not others. Team-scoped queries (which use REST) always return custom properties, but owner-scoped or name-based queries (which use GraphQL) do not, unless the user explicitly passes -AdditionalProperty 'CustomProperties'.

Request

All Get-GitHubRepository code paths that return [GitHubRepository] objects should include CustomProperties in their output by default, without requiring the user to pass -AdditionalProperty 'CustomProperties'.

What happens today

Code path	API	CustomProperties returned by default?
Get repo by name (-Owner -Name)	GraphQL	No — omitted from 48-property default list
Get my repo by name (-Name only)	GraphQL	No — omitted from same default list
List my repos (no params)	GraphQL	No — omitted from 5-property minimal list
List repos by owner (-Owner)	GraphQL	No — omitted from 5-property minimal list
List repos by team (-Owner -Team)	REST	Yes — REST API includes custom_properties automatically
Get repo by name and team	REST	Yes — REST API includes custom_properties automatically

What I expect

Every invocation of Get-GitHubRepository returns custom properties consistently, regardless of which parameter set is used. The behavior should not depend on whether the internal implementation uses REST or GraphQL.

Additionally, Get-GitHubRepositoryFork currently returns raw PSCustomObject responses instead of casting to [GitHubRepository], which means custom properties aren't surfaced through the typed class even though the REST API may include custom_properties in the response.

Acceptance criteria

• CustomProperties is included in the default $Property list for Get-GitHubRepositoryByName and Get-GitHubMyRepositoryByName
• CustomProperties is included in the default $Property list for Get-GitHubRepositoryListByOwner and Get-GitHubMyRepositories
• All code paths through Get-GitHubRepository return custom properties consistently
• Get-GitHubRepositoryFork casts output to [GitHubRepository] so custom properties (and other typed properties) are surfaced
• Other Get-* commands returning [GitHubRepository] are verified (no changes expected for Get-GitHubVariableSelectedRepository / Get-GitHubSecretSelectedRepository / New-GitHubRepository since those REST endpoints return minimal repo objects without custom_properties)

---

Technical decisions

Where to change — GraphQL "full" default lists: Add 'CustomProperties' to the default $Property array in Get-GitHubRepositoryByName (line ~37 in src/functions/private/Repositories/Get-GitHubRepositoryByName.ps1) and Get-GitHubMyRepositoryByName (line ~34 in src/functions/private/Repositories/Get-GitHubMyRepositoryByName.ps1). These functions already have a large 48-property default list; adding one more property is consistent and has negligible performance impact since these return a single repo.

Where to change — GraphQL "minimal" default lists: Add 'CustomProperties' to the default $Property array in Get-GitHubMyRepositories (line ~62 in src/functions/private/Repositories/Get-GitHubMyRepositories.ps1) and Get-GitHubRepositoryListByOwner (line ~71 in src/functions/private/Repositories/Get-GitHubRepositoryListByOwner.ps1). These currently default to only ('Name', 'Owner', 'Url', 'Size', 'Visibility'). Adding CustomProperties will add the repositoryCustomPropertyValues(first: 100) { nodes { propertyName value } } sub-query, which adds a small amount of overhead per repository in list queries. This is acceptable because: (a) custom properties are a core repository attribute users expect, (b) the sub-query is bounded at 100 values per repo, and (c) users who need maximum performance on list queries can already override $Property explicitly.

Get-GitHubRepositoryFork casting: Update Get-GitHubRepositoryFork (in src/functions/public/Repositories/Repositories/Get-GitHubRepositoryFork.ps1) to cast each response object to [GitHubRepository]::new($_) instead of returning raw $_.Response. This follows the same pattern used by Get-GitHubRepositoryListByTeam and Get-GitHubRepositoryByNameAndTeam. The REST constructor in GitHubRepository already handles custom_properties mapping, so no class changes are needed.

No changes for Get-GitHubVariableSelectedRepository / Get-GitHubSecretSelectedRepository: These endpoints return minimal repository objects from the GitHub API that do not include custom_properties. The [GitHubRepository] constructor gracefully handles the absence (sets CustomProperties to empty). No code changes needed — the limitation is in the API, not our code.

No changes for New-GitHubRepository variants: Repository creation endpoints rarely return custom_properties in the response. The [GitHubRepository] constructor handles this gracefully. No code changes needed.

No class changes: The GitHubRepository class already has the CustomProperties property, the GraphQL mapping in PropertyToGraphQLMap, and constructors for both REST (custom_properties) and GraphQL (repositoryCustomPropertyValues.nodes) formats. No modifications to the class are needed.

Breaking changes: None. Adding more data to the default output is additive. Users who override $Property explicitly are unaffected.

Test approach: No new unit tests required for the property list additions — these are configuration changes. The existing GraphQL query construction and class constructor tests cover the mechanics. Get-GitHubRepositoryFork already has #SkipTest:FunctionTest:Will add a test for this function in a future PR, so the casting change needs no immediate test addition, but if tests exist they should be verified.

---

Implementation plan

Core changes — GraphQL default property lists

• Add 'CustomProperties' to the default $Property array in Get-GitHubRepositoryByName (src/functions/private/Repositories/Get-GitHubRepositoryByName.ps1) — insert after 'GitUrl' at the end of the array
• Add 'CustomProperties' to the default $Property array in Get-GitHubMyRepositoryByName (src/functions/private/Repositories/Get-GitHubMyRepositoryByName.ps1) — same position
• Add 'CustomProperties' to the default $Property array in Get-GitHubMyRepositories (src/functions/private/Repositories/Get-GitHubMyRepositories.ps1) — change from @('Name', 'Owner', 'Url', 'Size', 'Visibility') to @('Name', 'Owner', 'Url', 'Size', 'Visibility', 'CustomProperties')
• Add 'CustomProperties' to the default $Property array in Get-GitHubRepositoryListByOwner (src/functions/private/Repositories/Get-GitHubRepositoryListByOwner.ps1) — same change

Get-GitHubRepositoryFork output casting

• Update Get-GitHubRepositoryFork (src/functions/public/Repositories/Repositories/Get-GitHubRepositoryFork.ps1) to cast output: change Write-Output $_.Response to iterate over response objects and cast each to [GitHubRepository]::new($_), following the pattern in Get-GitHubRepositoryListByTeam

Verification (no code changes expected)

• Verify Get-GitHubVariableSelectedRepository — confirm [GitHubRepository]::New($_) is used and no changes needed
• Verify Get-GitHubSecretSelectedRepository — confirm [GitHubRepository]::New($_) is used and no changes needed
• Verify New-GitHubRepository private variants — confirm all cast to [GitHubRepository]::New($_.Response) and no changes needed

[MariusStorhaug]

Restructured the issue description into the standard three-section format.

• Rewrote Context and request to focus on user-facing behavior: the inconsistency between REST-based (team) and GraphQL-based (owner/name) code paths
• Added comparison table showing which code paths currently include custom properties by default
• Added Technical decisions section based on codebase research:
  • Four GraphQL private functions need CustomProperties added to their default $Property arrays
  • Get-GitHubRepositoryFork needs [GitHubRepository] casting (currently returns raw PSCustomObject)
  • No changes needed for Get-GitHubVariableSelectedRepository, Get-GitHubSecretSelectedRepository, or New-GitHubRepository variants (REST API limitations, handled gracefully by constructors)
  • No class changes needed — GitHubRepository already supports both REST and GraphQL custom property formats
• Created Implementation plan with 8 tasks: 4 property list additions, 1 fork output casting fix, and 3 verification items
• Labels feature and minor are already applied and appropriate