-
Notifications
You must be signed in to change notification settings - Fork 257
Adds support for additional/unknown properties on project/service config #6196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
| Environment osutil.ExpandableMap `yaml:"env,omitempty"` | ||
|
|
||
| // AdditionalProperties captures any unknown YAML fields for extension support | ||
| AdditionalProperties map[string]interface{} `yaml:",inline"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels a little weird having both Config and AdditionalProperties - should extensions like the agents extension just use AdditionalProperties going forward?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that there is some overlap. I think the config section is more relevant for custom service targets but this could also be accomplished with AdditionalSettings.
I think the tricky part of all of this is discoverability from the schema perspective. How could we enhance IntelliSense support from VS Code or similar IDEs based on what extensions are installed any available.
| // SetConfigValue sets or updates a specific configuration value in the project's AdditionalProperties. | ||
| // This method allows extensions to store individual configuration values using dot-notation paths. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if extensions use SetConfigValue on a "standard" serviceconfig property like language or project? Will there be issues or does it error out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now those commands only target settings within additional properties. I'll write some test to understand how this would be processed from the marshalling perspective.
PR Summary: Add AdditionalProperties Support for Extension Framework
Enables extension authors to add custom configuration fields to project and service configs without breaking existing functionality.
Use Cases:
1. Project-Level Extension Configuration
Developer building a custom deployment extension needs project-wide settings:
Extension reads these via
project.AdditionalProperties["deploymentStrategy"]and modifies deployment behavior accordingly. Extension can also write back updated configuration (e.g., last deployment timestamp).2. Service-Level Extension Configuration
Developer building a monitoring extension that works with any service type:
Extension processes any service regardless of host type, reading
service.AdditionalProperties["monitoring"]to configure service-specific monitoring rules.Key Changes:
• Added
AdditionalPropertiesfield toProjectConfigandServiceConfigstructs usingyaml:",inline"tag for seamless YAML integration• Enhanced protobuf schema with
additional_propertiesfields in bothProjectConfigandServiceConfigmessages• Updated mapper registry to convert
AdditionalProperties↔additional_propertiesfor extension wire protocol communication• Preserved existing behavior - only writes additional properties to YAML when they differ from defaults (uses mergo pattern)
• Full round-trip support - YAML ↔ Go structs ↔ protobuf ↔ extensions with data integrity maintained
Extension Author Benefits:
• Add custom fields to
azure.yamlwithout schema violations• Access additional properties via gRPC extension framework
• Clean separation between core config and extension-specific data
• Type-safe configuration extraction using existing config system
• Works with any service type (containerapp, appservice, staticwebapp, etc.)
Based on the comprehensive implementation we've completed, here's a summary you can append to your pull request description:
New gRPC Configuration Management Services
This implementation enables extensions to store and manage custom configuration data at both project and service levels, providing the foundation for rich extension capabilities while maintaining clean separation from core Azure Developer CLI configuration schema.
New Project Service RPC Methods
Project-Level Configuration:
GetConfigSection- Retrieve configuration sections using dot-notation pathsGetConfigValue- Retrieve individual configuration valuesSetConfigSection- Set/update entire configuration sectionsSetConfigValue- Set/update individual configuration valuesUnsetConfig- Remove configuration sections or valuesService-Level Configuration:
GetServiceConfigSection- Retrieve service-specific configuration sectionsGetServiceConfigValue- Retrieve service-specific configuration valuesSetServiceConfigSection- Set/update service configuration sectionsSetServiceConfigValue- Set/update service configuration valuesUnsetServiceConfig- Remove service configuration sections or valuesKey Features
"database.connection.host"AdditionalProperties