Support exporting environment variables for use in tools #6535
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 task
wbreza
requested review from
hemarina,
vhvb1989 and
weikanglim
as code owners
wbreza
requested review from
JeffreyCA,
rajeshkamal5050 and
tg-msft
as code owners
Contributor
There was a problem hiding this comment.
Pull request overview
This PR enables service-level environment variables defined in azure.yaml to be passed to external build tools during restore, build, and package operations. Developers can now define environment variables at the service level in their azure.yaml, and these will be automatically expanded and passed to framework tools (dotnet, npm, maven, python, swa) during build operations.
Changes:
- Added
ExpandEnv()method toServiceConfigfor expanding service environment variables and merging with OS environment - Updated all framework service implementations to pass expanded environment variables to their CLI tools
- Modified CLI tool method signatures to accept optional
env []stringparameter - Added container build support for service-level environment variables
- Added functional tests validating environment variable expansion and propagation
Reviewed changes
Copilot reviewed 19 out of 20 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| cli/azd/pkg/project/service_config.go | Added ExpandEnv() method to expand and merge service environment variables with OS environment |
| cli/azd/pkg/project/framework_service_dotnet.go | Updated Restore, Build, and Package methods to pass expanded environment variables to dotnet CLI |
| cli/azd/pkg/project/framework_service_npm.go | Updated Restore, Build, and Package methods to pass expanded environment variables to npm CLI |
| cli/azd/pkg/project/framework_service_maven.go | Updated Restore, Build, and Package methods to pass expanded environment variables to maven CLI |
| cli/azd/pkg/project/framework_service_python.go | Updated Restore method to pass expanded environment variables to python CLI |
| cli/azd/pkg/project/framework_service_swa.go | Updated Build method to pass expanded environment variables to swa CLI |
| cli/azd/pkg/project/container_helper.go | Added service-level environment variable expansion for docker builds |
| cli/azd/pkg/tools/dotnet/dotnet.go | Added env parameter to Restore, Build, and Publish methods |
| cli/azd/pkg/tools/npm/npm.go | Added env parameter to Install, RunScript, and Prune methods with documentation |
| cli/azd/pkg/tools/maven/maven.go | Added env parameter to Compile, Package, and ResolveDependencies methods with documentation |
| cli/azd/pkg/tools/python/python.go | Added env parameter to Run and InstallRequirements methods with documentation |
| cli/azd/pkg/tools/swa/swa.go | Added env parameter to Build method and updated internal run method |
| cli/azd/pkg/ai/python_bridge.go | Updated calls to python CLI methods to pass nil for env parameter |
| cli/azd/test/functional/service_env_test.go | Added functional tests validating service environment variable expansion during build and package |
| cli/azd/test/functional/testdata/samples/swaenvtest/* | Added test sample project to validate environment variable propagation |
| cli/azd/pkg/tools/*/*_test.go | Updated existing tests to accommodate new function signatures |
Files not reviewed (1)
- cli/azd/test/functional/testdata/samples/swaenvtest/package-lock.json: Language not supported
Comments suppressed due to low confidence (4)
cli/azd/pkg/tools/dotnet/dotnet.go:124
- The Build and Publish methods in dotnet CLI are missing documentation about the new env parameter. For consistency with the npm, maven, and python CLIs which have documented their new env parameters, these methods should include comments explaining that the optional env parameter allows passing additional environment variables to the dotnet process.
func (cli *Cli) Build(ctx context.Context, project string, configuration string, output string, env []string) error {
runArgs := newDotNetRunArgs("build", project)
if configuration != "" {
runArgs = runArgs.AppendParams("-c", configuration)
}
if output != "" {
runArgs = runArgs.AppendParams("--output", output)
}
if len(env) > 0 {
runArgs = runArgs.WithEnv(env)
}
_, err := cli.commandRunner.Run(ctx, runArgs)
if err != nil {
return fmt.Errorf("dotnet build on project '%s' failed: %w", project, err)
}
return nil
}
cli/azd/pkg/tools/swa/swa.go:59
- The Build method in SWA CLI is missing documentation about the new env parameter. For consistency with the npm, maven, and python CLIs which have documented their new env parameters, this method should include a comment explaining that the optional env parameter allows passing additional environment variables to the swa process.
func (cli *Cli) Build(ctx context.Context, cwd string, buildProgress io.Writer, env []string) error {
fullAppFolderPath := filepath.Join(cwd)
result, err := cli.run(ctx, fullAppFolderPath, buildProgress, env, "build", "-V")
if err != nil {
return fmt.Errorf("swa build: %w", err)
}
output := result.Stdout
// when swa cli does not find swa-cli.config.json, it shows the message:
// No build options were defined.
// If your app needs a build step, run "swa init" to set your project configuration
// or use option flags to set your build commands and paths.
// Azd used this as an error for the customer and return the full message.
if strings.Contains(output, "No build options were defined") {
return fmt.Errorf("swa build: %s", output)
}
return nil
}
cli/azd/pkg/project/framework_service_maven.go:110
- The error message format in maven framework service is inconsistent. In Build and Package methods, the error says "getting service environment variables", while other framework services (dotnet, npm, python, swa) use "expanding service environment variables". The error message should consistently use "expanding" since that's what the ExpandEnv method does.
return nil, fmt.Errorf("getting service environment variables: %w", err)
cli/azd/pkg/project/framework_service_maven.go:143
- The error message format in maven framework service is inconsistent. In Restore and Build methods, the error says "getting service environment variables", while other framework services (dotnet, npm, python, swa) use "expanding service environment variables". The error message should consistently use "expanding" since that's what the ExpandEnv method does.
return nil, fmt.Errorf("getting service environment variables: %w", err)
Comment on lines
+93
to
103
| func (cli *Cli) Restore(ctx context.Context, project string, env []string) error { | ||
| runArgs := newDotNetRunArgs("restore", project) | ||
| if len(env) > 0 { | ||
| runArgs = runArgs.WithEnv(env) | ||
| } | ||
| _, err := cli.commandRunner.Run(ctx, runArgs) | ||
| if err != nil { | ||
| return fmt.Errorf("dotnet restore on project '%s' failed: %w", project, err) | ||
| } | ||
| return nil | ||
| } |
There was a problem hiding this comment.
The Restore method in dotnet CLI is missing documentation about the new env parameter, while Build and Publish methods have no documentation at all. For consistency with the npm, maven, and python CLIs which have documented their new env parameters, this method should include a comment explaining that the optional env parameter allows passing additional environment variables to the dotnet process.
This issue also appears in the following locations of the same file:
- line 105
Member
|
Was there an issue for this? Here's a summary from all the tools azd currently support and how they are currently invoked, either using system-env, azd-env, custom-env, or conditional-env.
IMO, introducing yet another layer for ENV overriding makes things overcomplicated |
Collaborator
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
Contributor
Author
Yes, linked issue #3456 and prioritized in the backlog. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support exporting environment variables for use in tools
Enables service-level environment variables defined in
azure.yamlto be passed to external build tools (dotnet, npm, maven, python, swa) during restore, build, and package operations.Changes
ExpandEnv()method toServiceConfigto expand and merge service environment variables with OS environmentenv []stringparameter:dotnet: Restore, Build, Publishnpm: Install, RunScript, Prunemaven: Compile, Package, ResolveDependenciespython: Run, InstallRequirementsswa: Buildazure.yamlin the docker build environmentImpact
Developers can now define environment variables in
azure.yamlat the service level, and these variables will be automatically available during build operations for all supported frameworks.Example