Conversation
Address PR review feedback: instead of a --built-in boolean toggle, use a --source flag that accepts any combination of built-in, user, and project. This is more consistent with the three-source model the document already describes and gives users a way to filter to user/project profiles in addition to built-ins. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| | Field | Type | Required | Description | | ||
| |-------|------|----------|-------------| | ||
| | `sku` | string | no | Azure SKU identifier. Metadata only — not used for resolution. | | ||
| | `status` | string | no | `GA`, `preview`, `deprecated`. CLI warns on deprecated profiles. | |
There was a problem hiding this comment.
Is GA a well known enough term? Would something like stable or latest be better?
There was a problem hiding this comment.
Some of this was pulled from the SKU docs. I think stable would be a better terminology.
| func profile list --source built-in,project # Combine sources (comma-separated) | ||
| func profile list --json # Machine-readable output | ||
| func profile show flex # Detailed view of a specific profile (resolved) | ||
| func profile show staging --raw # Show without inheritance resolution |
There was a problem hiding this comment.
Don't we need a command to remove a profile?
Also, we may need a background/auto cleanup mechanism to remove old/unused host versions. Otherwise, this feature may accumulate different host versions and consume customer's disk space.
There was a problem hiding this comment.
Don't we need a command to remove a profile?
Are you talking about the option to remove a custom profile? The current commands don't expose any authoring experiences. The initial experience to define, remove, modify profiles will be based on documentation. We'll also have our built-in profiles on GitHub for reference (in addition to show dumping the details).
Also, we may need a background/auto cleanup mechanism to remove old/unused host versions. Otherwise, this feature may accumulate different host versions and consume customer's disk space.
I'm not expecting to tie this to profiles, but to workloads instead, as ultimately, this pruning would be required for all workloads.
| - **OS-level behavior differences**: A developer on macOS using the `windows-consumption` profile will get the correct host version but not Windows-specific OS behaviors. | ||
| - **SKU-specific scale/networking/billing**: Consumption cold-start behavior, VNET integration, instance limits, etc. are not emulated. | ||
|
|
||
| > NOTE: Planned future iterations of CLI will support running on target environment containers, more closely aligning with the cloud environments. |
There was a problem hiding this comment.
Shouldn't this be in P0/P1 list of this feature(profiles) instead of future iterations?, running host on the specific OS (same as SKU)
There was a problem hiding this comment.
Not for the current scope. The goal of this initial scope is to match the runtime expectations of the current Core Tools experience, while providing the ability to install the Functions dependencies and the flexibility to run them side-by-side.
Virtualization, running on containers or emulating other managed environment behaviors are not within scope for the initial iteration.
Reframes func setup based on architectural review: - Identity: machine readiness orchestrator, not a UX wrapper or project bootstrapper. Coordinates workload install, profile pre-install, cache priming, first-run hints. - Drops the setup-side 'profile' concept. The word is reserved for cli-profiles.md (PR #4913). Replaced by --workloads. - User-level mutations only. No writes to .func/config.json or other project files (avoids collision with the profiles proposal). - Telemetry consent moved out of scope; it is a global first-CLI- invocation concern, not setup's job. - Re-run model pinned to idempotent additive reconciliation; adds --check. No manifest, no removal. - Explicit boundary section: init, setup, and start each own one verb and never call each other.
7 participants
Proposal for profile support in the CLI
Pull request checklist
release_notes.md