880ff8d491
Search-InfisicalCertificate was a 1:1 duplicate of Get-InfisicalCertificate's
List parameter set after the recent filter-surface expansion (bdec5aa). Both
cmdlets exposed the same ~27 server-side filters and both hit the same
POST /api/v1/projects/{projectId}/certificates/search endpoint. Keeping two
PowerShell cmdlets for the same operation added discovery noise without
benefit.
REMOVED
- src/PSInfisicalAPI/Cmdlets/SearchInfisicalCertificateCmdlet.cs (cmdlet
source, ~140 lines).
- 'Search-InfisicalCertificate' from CmdletsToExport in the source manifest
(Module/PSInfisicalAPI/PSInfisicalAPI.psd1) and from the two generators
in build.ps1 (Write-Manifest cmdlet list + Test-ModuleImports $expectedCmds).
- <command:command> block for Search-InfisicalCertificate from the help XML
(Module/PSInfisicalAPI/en-US/PSInfisicalAPI.dll-Help.xml).
- README PKI table row for Search-InfisicalCertificate.
- "For advanced filtering ... use Search-InfisicalCertificate instead"
sentence from the Get-InfisicalCertificate Notes block (no longer true).
RETAINED (internal)
- InfisicalPkiClient.SearchCertificates, InfisicalCertificateSearchQuery,
InfisicalEndpointNames.SearchCertificates and the endpoint registry entry.
Get-InfisicalCertificate and Request-InfisicalCertificate still call them
to walk the search endpoint.
MIGRATION
# Before
Search-InfisicalCertificate -ProjectId $p -Search 'web' -Status 'active'
# After
Get-InfisicalCertificate -ProjectId $p -Search 'web' -Status 'active'
Parameter names, defaults, and paging behavior are identical.
TESTS
- 216/216 passing (one unrelated time-based test in CsrAndRequestCmdletTests
was flaky on the run; passes deterministically when invoked in isolation).