DeployTo setting supported as environment variable #1702
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR enables the use of environment variables for the DeployTo setting in GitHub environments. The key changes include:
- Adding new workflow inputs (environmentName and environmentDeployToVariableValue) in multiple YAML workflow files.
- Updating the ReadSettings action to pass the new inputs to the underlying PowerShell script.
- Extending the existing workflows to support external configuration through environment variables.
Reviewed Changes
Copilot reviewed 4 out of 7 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| Templates/Per Tenant Extension/.github/workflows/PublishToEnvironment.yaml | Added environment variable parameters to support DeployTo settings |
| Templates/Per Tenant Extension/.github/workflows/CICD.yaml | Added environment variable parameters to support DeployTo settings |
| Templates/AppSource App/.github/workflows/CICD.yaml | Added environment variable parameters to support DeployTo settings |
| Actions/ReadSettings/action.yaml | Updated action inputs and run command to handle new environment variable settings |
Files not reviewed (3)
- Actions/AL-Go-Helper.ps1: Language not supported
- Actions/ReadSettings/ReadSettings.ps1: Language not supported
- Templates/AppSource App/.github/workflows/PublishToEnvironment.yaml: Language not supported
Comments suppressed due to low confidence (4)
Templates/Per Tenant Extension/.github/workflows/PublishToEnvironment.yaml:149
- [nitpick] Consider renaming 'environmentDeployToVariableValue' to a more concise name (e.g., 'deployToVar') to improve clarity and reduce verbosity.
environmentDeployToVariableValue: ${{ vars.DeployTo }}
Templates/Per Tenant Extension/.github/workflows/CICD.yaml:287
- [nitpick] Consider adopting a shorter name for 'environmentDeployToVariableValue' for consistency and better readability across workflow files.
environmentDeployToVariableValue: ${{ vars.DeployTo }}
Templates/AppSource App/.github/workflows/CICD.yaml:273
- [nitpick] Consider using a shorter, more concise name for 'environmentDeployToVariableValue' for improved maintainability and consistency.
environmentDeployToVariableValue: ${{ vars.DeployTo }}
Actions/ReadSettings/action.yaml:24
- [nitpick] Consider renaming the 'environmentDeployToVariableValue' input to a shorter name (e.g., 'deployToVar') to enhance clarity and consistency with other workflow files.
environmentDeployToVariableValue:
Actions/AL-Go-Helper.ps1
Outdated
| @@ -746,6 +748,12 @@ function ReadSettings { | |||
| $projectSettingsObject = GetSettingsObject -Path (Join-Path $projectFolder $ALGoSettingsFile) | |||
| $settingsObjects += @($projectSettingsObject) | |||
| } | |||
| if ($environmentDeployToVariableValue) { | |||
| # Read settings from environment variable (parameter) | |||
There was a problem hiding this comment.
You should include in the description above at which location in the order will the environment variable DeployTo be applied.
I think the DeployTo defined on the environment should be applied AFTER the other settings files - so that you can define specific settings for DeployTo under the environment and it wins over the generic settings files.
This location is before the settings files - meaning that settings files will win.
You need to call the mergeCustomObjectIntoOrdered...
| @@ -269,6 +269,8 @@ jobs: | |||
| with: | |||
| shell: ${{ matrix.shell }} | |||
| get: type,powerPlatformSolutionFolder | |||
| environmentName: ${{ matrix.environment }} | |||
There was a problem hiding this comment.
During initialize, we determine which environments should be included in continuous deployment. This is done by reading the settings and checking for ContinuousDeployment in the DeployTo structure.
There you need to peek into the environment's DeployTo variable as well (if exists) to see whether the environment should be included at all.
There was a problem hiding this comment.
Right that make sense, I'll take a look at that.
There was a problem hiding this comment.
Remember that github environments are only available in public repos or paid SKUs of GitHub - on private repos in free SKUs they are not available and you can use the environments setting to add environments.
You obviously cannot support environment variables when environments are not supported - we just need to make sure it doesn't fail when you peek into the variables of the environments.
There was a problem hiding this comment.
We should be good in private repos as well. The documentation for the vars context says that any configuration variable that has not been will return an empty string. Since org, repo and environment variables all exist in the vars context, there should be no problem, but just to be sure, I'll run a test in a private repo to verify:
https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#example-usage-of-the-vars-context
…entEnvironment action.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Actions/DetermineDeploymentEnvironments/DetermineDeploymentEnvironments.ps1
Fixed
Show fixed
Hide fixed
Actions/DetermineDeploymentEnvironments/DetermineDeploymentEnvironments.ps1
Fixed
Show fixed
Hide fixed
Actions/DetermineDeploymentEnvironments/DetermineDeploymentEnvironments.ps1
Fixed
Show fixed
Hide fixed
Actions/DetermineDeploymentEnvironments/DetermineDeploymentEnvironments.ps1
Fixed
Show fixed
Hide fixed
…rity over settings file.
With this change, it is now possible to define your DeployTo setting as an environment variable in your GitHub environments.