|
1 | 1 | # Aspire CLI config sources |
2 | 2 |
|
3 | | -**Status:** Configuration acquisition, allowlisted app-file materialization, and named agent skill sources are implemented in the CLI. Other content-acquisition customizations remain proposed. |
| 3 | +**Status:** Configuration acquisition, allowlisted app-file materialization, named agent skill sources, and named integration sources are implemented in the CLI. Other content-acquisition customizations remain proposed. |
4 | 4 |
|
5 | 5 | For example developer journeys, see [Microsoft first-party config-source scenarios](cli-config-sources-1p-scenarios.md). |
6 | 6 |
|
@@ -133,6 +133,7 @@ Only explicitly allowlisted top-level settings may be copied. Each supplied sect |
133 | 133 | | Setting | Purpose | |
134 | 134 | |---|---| |
135 | 135 | | `skillSources` | Named agent skill sources and all their settings | |
| 136 | +| `integrationSources` | Named NuGet integration feeds and allowed package patterns | |
136 | 137 |
|
137 | 138 | Use the same root-only normalization for local settings and source files before matching the allowlist, and match top-level names case-insensitively like other CLI settings. Root-level flat colon-separated keys merge into existing nested sections regardless of casing. Normalize source files before configuration-provider validation; genuine duplicate nested leaves remain validation errors. Nested colon keys remain literal, including profile names, environment-variable names, and custom skill-source keys such as `{"skillSources":{"team":{"custom:key":"..."}}}`. These keys are copied unchanged when their top-level section is allowed. There is no source-specific normalization. |
138 | 139 |
|
@@ -353,6 +354,32 @@ The allowlist copies the entire supplied `skillSources` section, including arbit |
353 | 354 | |---|---|---| |
354 | 355 | | Skills | `aspire agent init` registers all configured native sources by default; `--aspire-source embedded` installs bundled skill files | Additional validated bundles, selected/default skills, and workspace installation destinations | |
355 | 356 | | Templates | .NET templates are installed from NuGet; CLI-native starters use embedded files or scaffolding | Template catalogs, package identities, versions, and feeds; external starter content could follow later | |
356 | | -| Integrations | Templates declare dependencies; `aspire add` and integration list/search discover NuGet packages | Additional catalog entries, package versions, feeds, and package-source mappings | |
| 357 | +| Integrations | Templates declare dependencies; `aspire add` and integration list/search discover packages from all configured NuGet integration sources | Additional catalog metadata and package-version constraints | |
| 358 | + |
| 359 | +### Named integration sources |
| 360 | + |
| 361 | +Configure integration discovery independently of the AppHost's SDK channel: |
| 362 | + |
| 363 | +```json |
| 364 | +{ |
| 365 | + "integrationSources": { |
| 366 | + "default": {}, |
| 367 | + "team": { |
| 368 | + "source": "https://packages.example.com/v3/index.json", |
| 369 | + "patterns": ["Contoso.Hosting.*", "Contoso.SpecialIntegration"] |
| 370 | + } |
| 371 | + } |
| 372 | +} |
| 373 | +``` |
| 374 | + |
| 375 | +The implicit `default` entry retains existing channel and ambient NuGet discovery, including official and Community Toolkit packages. Set `default.enabled` to `false` to search only explicitly configured sources. An entry with a `source` can omit `patterns` to discover all packages from that feed, equivalent to `["*"]`; an explicitly supplied array must be non-empty. Override `default.source` to replace built-in discovery with a different feed, optionally specifying `default.patterns` to restrict its packages. |
| 376 | + |
| 377 | +Each enabled source is searched for matching package IDs, regardless of their namespace. Patterns use case-insensitive NuGet matching: an exact ID, a prefix ending in `*`, or `*` for every package. Other wildcard positions are invalid. Sources may be HTTP(S) NuGet service indexes or local package directories; relative directories resolve against the selected AppHost directory. Embedded credentials are rejected. Configure private-feed credentials using NuGet's existing credential mechanisms. |
| 378 | + |
| 379 | +Named entries referring to the same feed identity are combined before discovery. Their allowed patterns are unioned case-insensitively, disabled entries do not contribute patterns, and the first entry supplies the display name and source spelling. Integration discovery performs one search per feed using the patterns' common prefix (an empty query for unrelated prefixes), following pagination as needed, then filters results against the merged patterns. Local feeds are likewise enumerated once. The implicit built-in discovery entry remains separate. |
| 380 | + |
| 381 | +`aspire add`, `aspire integration list`, `aspire integration search`, and MCP integration discovery use the same configured sources. Stable and prerelease packages are included for custom sources, and the existing deprecated-package and optional polyglot-compatibility filters still apply. The selected source is used for version lookup. Adding a package persists an exact package-to-feed mapping in the AppHost's NuGet configuration, preserving ambient SDK and dependency feeds so subsequent restores can resolve the package. This does not change the AppHost's SDK channel. An explicit `aspire add --source` continues to override discovery. |
| 382 | + |
| 383 | +Sources and their fields merge case-insensitively across global and selected-app settings. As with `skillSources`, `configSource` can supply the entire `integrationSources` section. Materialization replaces a supplied section in full and preserves an omitted section. Refreshing configuration does not add packages or remove previously persisted NuGet mappings. |
357 | 384 |
|
358 | 385 | Keep standard content available initially and preserve explicit user selections and suppression options. Future source-driven content settings must be explicitly added to the allowlist and materialized before they affect acquisition choices. An availability notice never changes those choices. An explicit configuration update does not automatically regenerate applications or reinstall skills. Git access does not grant access to private package feeds, and all acquired content must retain its existing validation and authentication requirements. |
0 commit comments