testing bicep cicd - added new oidc client id for read-only access, t… #199
Conversation
This file contains 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
…esting what-if flag
Terraform Format and Style 🖌``Terraform Initialization ⚙️
|
Terraform Format and Style 🖌``Terraform Initialization ⚙️
|
thotheod
requested changes
Jan 16, 2024
There was a problem hiding this comment.
Why do we need this parameter folder? and why do we introduce these 3 sets of parameter files? If those are only required for the Github actions, we could possibly just override the different params without introducing several copies of the same param file
There was a problem hiding this comment.
The thought around the parameter folder is to capture the various scenarios we wanted to test for/support as we introduced new changes into the project, and to make it easier for users to just work within a single file when looking to deploy their desired scenario.
Eventually, thinking we will have a single actions pipeline dedicated to each of the parameter files to ensure whenever there are relevant changes it will execute as part of the PR.
Definitely open to better ways of managing this but my concern with having multiple param files for single deployment would be more confusion for our users.
There was a problem hiding this comment.
I see the point, but this could eventually lead to having so many parameter files for several combinations of "feature flags"
i.e.
- App Service Plan / Windows / No Availability Zone
- App Service Plan / Windows / With Availability Zone
- App Service Plan / Linux / No Availability Zone
- App Service Plan / Linux / With Availability Zone
- ASE / Windows / No Availability Zone
- ASE / Windows / With Availability Zone
- ASE / Linux / No Availability Zone
- ASE / Linux / With Availability Zone
- etc etc.....
I think it should be OK to have just one parameter file with default settings for the more common scenario (whatever that could be - it could be even random, since the purpose of the param file is that the end user can easily parametrize the deployment). If we need to deploy different combinations (aka scenarios) with github actions, we could override the default params by using the flag --parameters <parameter-name>=<parameter-value> in the az deployment sub .... cli
i.e. something like
# for action that deploys ASEv3:
az deployment sub create -g "$SPOKE_RESOURCE_GROUP_NAME" \
-f main.bicep \
-p main.parameters.jsonc \
--name $LZA_DEPLOYMENT_SAMPLE_JAVA \
--parameters deployAseV3=true
# for action that deploys App Service Plan:
az deployment sub create -g "$SPOKE_RESOURCE_GROUP_NAME" \
-f main.bicep \
-p main.parameters.jsonc \
--name $LZA_DEPLOYMENT_SAMPLE_JAVA \
--parameters deployAseV3=false
There was a problem hiding this comment.
Makes sense, I'll remove the parameters dir and adjust the pipeline accordingly
There was a problem hiding this comment.
same as above:
Why do we need this parameter folder? and why do we introduce these 3 sets of parameter files? If those are only required for the Github actions, we could possibly just override the different params without introducing several copies of the same param file
There was a problem hiding this comment.
same as above:
Why do we need this parameter folder? and why do we introduce these 3 sets of parameter files? If those are only required for the Github actions, we could possibly just override the different params without introducing several copies of the same param file
Terraform Format and Style 🖌``Terraform Initialization ⚙️
|
Terraform Format and Style 🖌``Terraform Initialization ⚙️
|
Terraform Format and Style 🖌``Terraform Initialization ⚙️
|
Terraform Format and Style 🖌``Terraform Initialization ⚙️
|
Terraform Format and Style 🖌``Terraform Initialization ⚙️
|
thotheod
approved these changes
Jan 31, 2024
jonlester
pushed a commit
that referenced
this pull request
May 20, 2024
#199) * testing bicep cicd - added new oidc client id for read-only access, testing what-if flag * Adding region into the bicep yml, env var and to the what-if arm-deploy action * testing pipeline, adding puysh trigger for this branch * testing pipeline, adding puysh trigger for this branch * testing with prod id as the what-if scenario requires same level of permissions * testing with prod id as the what-if scenario requires same level of permissions * testing the deployment * testing the deployment * testing cicd bicep templates * testing cicd * testing cicd * testing cicd * disabling psrule for now * disabling psrule for now * consolidating tf scenario 1 workflows into a single cicd pipeline * consolidating tf scenario 1 workflows into a single cicd pipeline * consolidating tf scenario 1 workflows into a single cicd pipeline * consolidating tf scenario 1 workflows into a single cicd pipeline * renaming consolidated scenario 1 tf pipeline * Adding concurrency, removed redundant param files * Adding concurrency, removed redundant param files * removing test branch trigger * cleanup * cleanup
ibersanoMS
pushed a commit
that referenced
this pull request
Oct 1, 2024
#199) * testing bicep cicd - added new oidc client id for read-only access, testing what-if flag * Adding region into the bicep yml, env var and to the what-if arm-deploy action * testing pipeline, adding puysh trigger for this branch * testing pipeline, adding puysh trigger for this branch * testing with prod id as the what-if scenario requires same level of permissions * testing with prod id as the what-if scenario requires same level of permissions * testing the deployment * testing the deployment * testing cicd bicep templates * testing cicd * testing cicd * testing cicd * disabling psrule for now * disabling psrule for now * consolidating tf scenario 1 workflows into a single cicd pipeline * consolidating tf scenario 1 workflows into a single cicd pipeline * consolidating tf scenario 1 workflows into a single cicd pipeline * consolidating tf scenario 1 workflows into a single cicd pipeline * renaming consolidated scenario 1 tf pipeline * Adding concurrency, removed redundant param files * Adding concurrency, removed redundant param files * removing test branch trigger * cleanup * cleanup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This pull request includes various changes related to different scenarios, workflows, and configuration files. The most important changes include adding new deployment parameter files for different scenarios, removing GitHub Actions workflow files, and updating Terraform and Bicep configuration files.
Deployment and configuration changes:
scenarios/secure-baseline-multitenant/bicep/parameters/ase-zone-redundant.parameters.jsonc: Added a new deployment parameter file for the "ASE Zone Redundant Multitenant" scenario.scenarios/secure-baseline-multitenant/bicep/parameters/appsvc.parameters.json: Added a new deployment parameter file for the "ASE Zone Redundant Multitenant" scenario..psrule/ps-rule.yaml: Added a new section to the PSRule configuration file.Workflow changes:
.github/workflows/scenario2.bicep.yml: Removed a GitHub Actions workflow file for the "Scenario 2: Bicep Single-tenant ASEv3 Secure Baseline" scenario..github/workflows/scenario1.terraform.yml: Added a new job to the Terraform CI/CD process and updated the workflow name, branch, and paths. [1] [2] [3] [4].github/workflows/scenario1.terraform.spoke.yml: Removed the entire content of the.github/workflows/scenario1.terraform.spoke.ymlfile..github/workflows/.template.bicep.yml: Added a new workflow file that triggers on aworkflow_callevent and includes inputs for module path, Bicep parameter path, destroy flag, and region..github/workflows/scenario1.bicep.yml: Added a new workflow called "Scenario 1: Bicep Multi-Tenant ASEv3 Secure Baseline" and defined its behavior, triggers, permissions, environment variables, and jobs. (.github/workflows/scenario1.bicep.yml)Documentation changes:
scenarios/secure-baseline-multitenant/terraform/spoke/README.md: Updated the azurerm provider version and added a new input variable for the hub virtual network in the spoke module's README.md file. [1] [2]scenarios/secure-baseline-multitenant/terraform/hub/README.md: Updated the version of the azurerm provider in the hub module's README.md file.README.md: Updated the pipeline status table to include a new badge for the Bicep Multi-Tenant ASEv3 Secure Baseline scenario.Please note that the order of importance is subjective and can vary based on the context and requirements of the project.
Pipeline references
Type of Change
Please delete options that are not relevant.
Checklist