Skip to content

feat: auto-register repositories via PSDependOptions.Repositories (#50)#197

Draft
HeyItsGilbert wants to merge 1 commit into
mainfrom
worktree-glistening-petting-lovelace
Draft

feat: auto-register repositories via PSDependOptions.Repositories (#50)#197
HeyItsGilbert wants to merge 1 commit into
mainfrom
worktree-glistening-petting-lovelace

Conversation

@HeyItsGilbert

Copy link
Copy Markdown
Member

Summary

Closes #50. PSDepend DependencyFiles that reference a private repository currently break on any machine where that repository isn't pre-registered. This PR lets the DependencyFile declare the URL once, and PSDepend handles registration automatically.

  • Adds PSDependOptions.Repositories — a file-level hashtable mapping repository names to source URLs
  • PSGalleryModule, PSResourceGet, and Package DependencyScripts auto-register an unregistered repository if its name appears in the registry (persistent, Trusted, using the Dependency's Credential if present)
  • Warns (does not error) if a repository is already registered at a different URL
  • Test action is unchanged — never registers anything

Usage

@{
    PSDependOptions = @{
        Target = 'CurrentUser'
        Repositories = @{
            # PSGalleryModule / PSResourceGet: bare string URL
            MyPrivateGallery = 'https://my.feed/nuget'
            # Package: hashtable with Url + ProviderName
            MyNugetFeed      = @{ Url = 'https://my.feed/v3'; ProviderName = 'nuget' }
        }
    }
    'MyModule' = @{
        DependencyType = 'PSGalleryModule'
        Parameters     = @{ Repository = 'MyPrivateGallery' }
    }
}

Design decisions

An ADR is included at docs/adr/0001-repository-registry-in-psdependoptions.md capturing the key trade-offs: why file-level declaration over per-Dependency URL, and why persistent over ephemeral registration.

Seeking feedback on

  • Naming: Repositories in PSDependOptions — does this collide with anything in your setups?
  • The Package type requires a hashtable @{Url=…; ProviderName=…} while the module types take a bare string — is this acceptable or should the shape be unified?
  • Should Test return $false when the repository itself isn't registered, even if the module is installed? (Current implementation: no.)

Test plan

  • All existing Pester tests pass (verified locally: 241 passed, 2 skipped, 0 failed)
  • Manual test: PSGalleryModule against an unregistered private repo name with a matching Repositories entry
  • Manual test: URL mismatch warning fires when repo is already registered at a different URL
  • Manual test: PSResourceGet and Package equivalents

🤖 Generated with Claude Code

…ries

PSGalleryModule, PSResourceGet, and Package DependencyScripts now
check PSDependOptions.Repositories when a named repository is not
registered on the current machine. If a URL is declared there the
repository is registered persistently as Trusted before installation
proceeds, making DependencyFiles portable without manual setup.

Closes #50

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

Test Results

    3 files     66 suites   1m 22s ⏱️
  979 tests   925 ✅ 54 💤 0 ❌
1 311 runs  1 247 ✅ 64 💤 0 ❌

Results for commit 79df1bf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Register-PSRepository or Package Source if not registered

1 participant