ci: ensure unique revisions for deployments #1211
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe changes introduced in this pull request focus on enhancing the deployment process by adding a new environment variable, Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range comments (3)
.azure/applications/graphql/prod.bicepparam (1)
Line range hint
1-14: Consider adding a comment to explain the purpose ofrevisionSuffix.The addition of the
revisionSuffixparameter is well-implemented and consistent with the file's structure. To improve maintainability, consider adding a brief comment explaining its purpose and importance in ensuring unique deployments.Example:
// Unique suffix for each deployment to prevent conflicts when re-running workflows param revisionSuffix = readEnvironmentVariable('REVISION_SUFFIX').azure/applications/web-api-eu/main.bicep (1)
Incomplete Update of
revisionSuffixParameterThe
revisionSuffixparameter has been introduced inmain.bicepbut is not reflected in any of the related workflow YAML files or documentation. To ensure consistent deployment behavior and proper documentation:
Workflow Files:
.github/workflows/action-deploy-infra.yml.github/workflows/action-build-infrastructure.yml.github/workflows/action-deploy-apps.ymlAction: Update these workflows to include and pass the
revisionSuffixparameter when invoking the Bicep template.Documentation Files:
README.mdCHANGELOG.mddocs/Configuration.mdsrc/Digdir.Domain.Dialogporten.Janitor/README.mdAction: Document the new
revisionSuffixparameter, its purpose, and usage within these files to ensure clarity for all stakeholders.🔗 Analysis chain
Line range hint
1-114: Verify related files and documentation.The changes in this file successfully introduce the
revisionSuffixparameter to ensure unique revisions for deployments. However, to complete this change:
- Ensure that any workflow files (e.g., GitHub Actions) that call this Bicep template are updated to provide the
revisionSuffixparameter.- Update any relevant documentation to reflect this new parameter and its purpose.
To help verify the impact of this change, you can run the following script:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for potential workflow files that might need updating echo "Potential workflow files that might need updating:" fd -e yml -e yaml . .github/workflows -x grep -l "main.bicep" # Search for documentation files that might mention deployment revisions echo "Documentation files that might need updating:" rg -t md -l "revision|deployment|container app"Length of output: 550
Script:
#!/bin/bash # Verify 'revisionSuffix' parameter in workflow YAML files echo "Checking for 'revisionSuffix' in workflow files:" grep -Hn "revisionSuffix" .github/workflows/action-deploy-infra.yml .github/workflows/action-build-infrastructure.yml .github/workflows/action-deploy-apps.yml # Verify documentation updates for 'revisionSuffix' in markdown files echo "Checking for documentation updates related to 'revisionSuffix':" grep -iHn "revisionSuffix" README.md CHANGELOG.md docs/Configuration.md src/Digdir.Domain.Dialogporten.Janitor/README.mdLength of output: 535
.github/workflows/action-deploy-apps.yml (1)
Line range hint
1-293: Suggestions for consistency and completenessThe changes effectively address the issue of duplicate revision suffixes in the
deploy-appsjob. However, consider the following suggestions to improve consistency and completeness:
Apply the
REVISION_SUFFIXto thedeploy-migration-jobanddeploy-jobsjobs as well to ensure all deployments have unique revisions.Include the
REVISION_SUFFIXin thedeploymentNameparameter for all jobs to prevent potential conflicts when multiple deployments are triggered for the same version. For example:deploymentName: dp-be-${{ inputs.environment }}-${{ matrix.name }}-${{ inputs.version }}-${{ env.REVISION_SUFFIX }}
- If you implement the suggestion to define
REVISION_SUFFIXat the job or workflow level, update all references accordingly.These changes would ensure that the fix is applied consistently across all deployment jobs and further reduce the risk of conflicts.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
📒 Files selected for processing (13)
- .azure/applications/graphql/main.bicep (2 hunks)
- .azure/applications/graphql/prod.bicepparam (1 hunks)
- .azure/applications/graphql/staging.bicepparam (1 hunks)
- .azure/applications/graphql/test.bicepparam (1 hunks)
- .azure/applications/web-api-eu/main.bicep (2 hunks)
- .azure/applications/web-api-eu/prod.bicepparam (1 hunks)
- .azure/applications/web-api-eu/staging.bicepparam (1 hunks)
- .azure/applications/web-api-eu/test.bicepparam (1 hunks)
- .azure/applications/web-api-so/main.bicep (2 hunks)
- .azure/applications/web-api-so/prod.bicepparam (1 hunks)
- .azure/applications/web-api-so/staging.bicepparam (1 hunks)
- .azure/applications/web-api-so/test.bicepparam (1 hunks)
- .github/workflows/action-deploy-apps.yml (2 hunks)
🔇 Additional comments (16)
.azure/applications/graphql/prod.bicepparam (1)
7-7: LGTM! This change aligns well with the PR objectives.The addition of the
revisionSuffixparameter, which reads from theREVISION_SUFFIXenvironment variable, is a good implementation to ensure unique revisions for deployments. This directly addresses the issue mentioned in the PR objectives and should prevent failures due to duplicate revision suffixes when re-running workflows..azure/applications/graphql/test.bicepparam (1)
7-7: LGTM: New parameter added to ensure unique revisionsThe addition of the
revisionSuffixparameter, which reads its value from theREVISION_SUFFIXenvironment variable, aligns well with the PR objectives. This change will help ensure unique revisions for each deployment, preventing conflicts when re-running workflows.A few points to consider:
- The implementation is consistent with other parameters in the file (e.g.,
imageTag).- This change supports the goal of making each deployment have a distinct revision suffix.
- Ensure that the
REVISION_SUFFIXenvironment variable is properly set in the CI/CD pipeline before this deployment step.To verify the usage of this new parameter, please run the following script:
.azure/applications/web-api-eu/prod.bicepparam (1)
7-7: LGTM! This change addresses the PR objectives effectively.The addition of the
revisionSuffixparameter, which reads from theREVISION_SUFFIXenvironment variable, aligns perfectly with the PR's goal of ensuring unique revisions for deployments. This implementation will help prevent failures associated with duplicate identifiers when re-running workflows.The parameter is correctly implemented and consistent with other environment variable readings in the file. This change enhances the reliability of the deployment process without disrupting the existing configuration.
.azure/applications/web-api-eu/test.bicepparam (1)
7-7: LGTM! The new parameter aligns with PR objectives.The addition of the
revisionSuffixparameter, which reads from theREVISION_SUFFIXenvironment variable, is well-implemented and aligns perfectly with the PR objectives. This change will ensure unique revisions for deployments, addressing the issue of workflow failures due to identical revision suffixes.A few observations:
- The implementation is consistent with other parameters in the file.
- Using
readEnvironmentVariableallows for dynamic assignment of the revision suffix, which is crucial for achieving uniqueness across deployments.- The placement of the new parameter (after
imageTagand before the secrets section) is logical and maintains good code organization.To ensure this change is properly utilized, let's verify if the
REVISION_SUFFIXenvironment variable is set in the relevant workflow files:✅ Verification successful
REVISION_SUFFIX is correctly set in workflow files.
The
REVISION_SUFFIXenvironment variable is properly defined in.github/workflows/action-deploy-apps.ymlusing a combination ofgithub.run_id,inputs.version, andgithub.run_attempt. This ensures that each deployment has a unique revision suffix, aligning with the PR objectives.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if REVISION_SUFFIX is set in workflow files # Test: Search for REVISION_SUFFIX in yaml files under .github/workflows # Expect: At least one occurrence setting REVISION_SUFFIX rg --type yaml 'REVISION_SUFFIX' .github/workflowsLength of output: 326
.azure/applications/web-api-so/prod.bicepparam (2)
Line range hint
1-13: The overall file structure and practices look good.The file correctly uses environment variables for sensitive information and configuration, which is a good security practice. The parameters are appropriately defined for a production environment, and the existing parameters remain unchanged. This approach maintains consistency while introducing the new
revisionSuffixparameter.
7-7: LGTM! The addition ofrevisionSuffixparameter aligns with the PR objectives.The new parameter
revisionSuffixis correctly implemented to read from theREVISION_SUFFIXenvironment variable. This change should address the issue of deployment failures due to identical revision suffixes when re-running workflows.To ensure this change is effective, please verify that the
REVISION_SUFFIXenvironment variable is correctly set in your CI/CD pipeline. You can use the following script to check if the variable is present in your GitHub Actions workflow:If the variable is not found, you may need to update your workflow files to set this variable using the GitHub Actions run ID and attempt number, as mentioned in the PR description.
✅ Verification successful
LGTM! The addition of the
revisionSuffixparameter aligns with the PR objectives.The
REVISION_SUFFIXenvironment variable is correctly set in your GitHub Actions workflows as confirmed by the verification script output. This change should effectively address the issue of deployment failures due to identical revision suffixes when re-running workflows.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if REVISION_SUFFIX is set in GitHub Actions workflow files # Test: Search for REVISION_SUFFIX in workflow files rg --type yaml 'REVISION_SUFFIX' .github/workflowsLength of output: 326
.azure/applications/web-api-so/test.bicepparam (2)
Line range hint
1-14: Summary: Successful implementation of unique revision suffix.The addition of the
revisionSuffixparameter is a focused and effective change that addresses the issue described in the PR objectives. By reading from an environment variable, it allows for dynamic setting of a unique identifier for each deployment.This change:
- Solves the problem of duplicate revision suffixes when re-running workflows.
- Improves the reliability of the deployment process.
- Is minimally invasive, affecting only the necessary part of the configuration.
No further changes are required in this file. The implementation is clean and aligns well with the project's needs.
7-7: LGTM: New parameter added for unique revision suffix.The addition of the
revisionSuffixparameter aligns well with the PR objectives. It reads the value from theREVISION_SUFFIXenvironment variable, which will be set to a unique value for each deployment using the workflow run ID and attempt number.This change effectively addresses the issue of duplicate revision suffixes when re-running workflows, ensuring that each deployment has a unique identifier.
To verify that this change is properly implemented in the workflow, we can check the relevant workflow file:
This script will search for the setting of
REVISION_SUFFIXin the workflow files, ensuring it's set to a combination ofgithub.run_idandgithub.run_attemptas described in the PR objectives.✅ Verification successful
LGTM: REVISION_SUFFIX is correctly set with a unique identifier including version.
The
revisionSuffixparameter is properly configured to includegithub.run_id,inputs.version, andgithub.run_attempt, ensuring each deployment has a unique identifier. This implementation aligns with the PR objectives and effectively prevents duplicate revision suffixes.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the REVISION_SUFFIX is set in the workflow # Test: Search for REVISION_SUFFIX in workflow files rg --type yaml 'REVISION_SUFFIX.*\$\{\{ github.run_id \}\}-\$\{\{ github.run_attempt \}\}' .github/workflows/Length of output: 111
Script:
#!/bin/bash # Description: Check for any occurrences of REVISION_SUFFIX in workflow YAML files rg --type yaml 'REVISION_SUFFIX' .github/workflows/Length of output: 327
Script:
#!/bin/bash # Description: Analyze the usage of REVISION_SUFFIX in deployment workflows # Search for all instances where REVISION_SUFFIX is used rg --type yaml 'REVISION_SUFFIX' .github/workflows/ | while read -r line; do echo "$line" doneLength of output: 666
.azure/applications/graphql/staging.bicepparam (1)
7-7: LGTM! This change aligns well with the PR objectives.The addition of the
revisionSuffixparameter, which reads from theREVISION_SUFFIXenvironment variable, directly addresses the issue of ensuring unique revisions for deployments. This implementation will prevent failures when re-running workflows, as each deployment will now have a distinct revision suffix..azure/applications/web-api-eu/staging.bicepparam (1)
7-7: LGTM: New parameter aligns with PR objectivesThe addition of the
revisionSuffixparameter, which reads its value from theREVISION_SUFFIXenvironment variable, aligns well with the PR objectives. This change addresses the issue of deployment failures due to identical revision suffixes by allowing a unique suffix to be passed for each deployment.A few points to consider:
- The implementation is correct and follows the pattern used for other parameters in this file.
- This change doesn't impact existing parameters, maintaining backward compatibility.
- The use of an environment variable allows for dynamic setting of the revision suffix, which is ideal for CI/CD workflows.
To ensure this change is properly utilized, let's verify if the
REVISION_SUFFIXenvironment variable is set in the relevant workflow files:This will help confirm that the new parameter is being used as intended in the CI/CD process.
✅ Verification successful
LGTM:
revisionSuffixparameter is correctly integrated and utilizedThe
revisionSuffixparameter successfully reads theREVISION_SUFFIXenvironment variable, which is properly set in the CI/CD workflow files. This ensures each deployment has a unique suffix, effectively addressing the issue of deployment failures due to identical revision suffixes.
- The environment variable
REVISION_SUFFIXis defined in.github/workflows/action-deploy-apps.yml:
REVISION_SUFFIX: "${{ github.run_id }}-${{ inputs.version }}-${{ github.run_attempt}}"No further actions are required as the implementation meets the PR objectives and maintains existing functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if REVISION_SUFFIX is set in workflow files # Test: Search for REVISION_SUFFIX in workflow files rg --type yaml 'REVISION_SUFFIX' .github/workflowsLength of output: 326
.azure/applications/graphql/main.bicep (2)
19-21: LGTM: New parameterrevisionSuffixis well-defined.The new
revisionSuffixparameter is correctly declared with an appropriate description and constraint. It follows the existing coding style and conventions used in the file.
94-94: Verify the usage of bothrevisionSuffixandimageTagparameters.The addition of the
revisionSuffixparameter to thecontainerAppmodule is correct and aligns with the PR objectives. However, the AI-generated summary mentioned thatrevisionSuffixreplaces the previous usage ofimageTag, but both parameters are still present in the module call.Please run the following script to verify the usage of both parameters in the
containerAppmodule:If both parameters are indeed needed, please update the PR description to clarify this point.
.azure/applications/web-api-eu/main.bicep (1)
19-21: LGTM: New parameterrevisionSuffixis well-defined.The new
revisionSuffixparameter is correctly declared with an appropriate description and constraint. It follows the existing coding style and conventions used in the file..azure/applications/web-api-so/main.bicep (2)
19-21: LGTM: New parameterrevisionSuffixadded correctly.The new
revisionSuffixparameter is well-defined with an appropriate description and constraint. This addition aligns with the PR objective of ensuring unique revisions for deployments.
101-101: Verify uniqueness ofrevisionSuffixin workflow.The change correctly implements the use of
revisionSuffixin thecontainerAppmodule, which aligns with the PR objective. This should prevent conflicts when re-running workflows.Please ensure that the
revisionSuffixparameter is set to a unique value for each workflow run. You can verify this by checking the workflow file where this Bicep template is used. The workflow should setrevisionSuffixusing unique identifiers like${{ github.run_id }}-${{ github.run_attempt }}..github/workflows/action-deploy-apps.yml (1)
169-169: LGTM: Unique revision suffix for dry run deploymentsThe introduction of the
REVISION_SUFFIXenvironment variable is a good solution to ensure unique revisions for each deployment. By combininggithub.run_id,inputs.version, andgithub.run_attempt, it guarantees a unique identifier for each workflow run, addressing the issue mentioned in the PR objectives.
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
📒 Files selected for processing (1)
- .github/workflows/action-deploy-apps.yml (3 hunks)
🔇 Additional comments (2)
.github/workflows/action-deploy-apps.yml (2)
152-153: Excellent addition of theREVISION_SUFFIXenvironment variable.The introduction of the
REVISION_SUFFIXenvironment variable, composed ofgithub.run_id,inputs.version, andgithub.run_attempt, directly addresses the issue of deployment failures due to duplicate revision suffixes. This ensures that each deployment, even when re-running the same workflow, will have a unique identifier.
152-153: Summary: Effective implementation of unique revision suffixesThe changes introduced in this pull request successfully address the issue of deployment failures due to duplicate revision suffixes. By implementing a
REVISION_SUFFIXenvironment variable that combines the GitHub run ID, version, and run attempt, the workflow now ensures that each deployment has a unique identifier.Key points:
- The
REVISION_SUFFIXis correctly defined at the job level.- It's consistently applied in both dry run and actual deployment steps.
- The changes are minimal and focused, reducing the risk of introducing new issues.
These modifications align well with the PR objectives and should resolve the deployment conflicts when re-running workflows. The implementation is clean and effective.
Also applies to: 171-171, 195-195
<!--- Provide a general summary of your changes in the Title above -->
There was an issue where if we re-run the same workflow for deployment,
it would fail because of using the same revision suffix. Changing to
passing in a revision suffix and using workflow run id and workflow
attempt to ensure uniqueness.
<!--- Describe your changes in detail -->
- #{issue number}
- [ ] **Your** code builds clean without any errors or warnings
- [ ] Manual testing done (required)
- [ ] Relevant automated test added (if you find this hard, leave it and
we'll help out)
- [ ] Documentation is updated (either in `docs`-directory, Altinnpedia
or a separate linked PR in
[altinn-studio-docs.](https://github.com/Altinn/altinn-studio-docs), if
applicable)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
- **New Features**
- Introduced a new environment variable `REVISION_SUFFIX` for improved
tracking of deployment revisions.
- Added a `revisionSuffix` parameter across various Bicep configuration
files to enhance deployment customization and versioning.
- Standardized deployment names to include environment and version for
consistency.
- **Chores**
- Enhanced deployment workflow structure without altering the overall
functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Description
There was an issue where if we re-run the same workflow for deployment, it would fail because of using the same revision suffix. Changing to passing in a revision suffix and using workflow run id and workflow attempt to ensure uniqueness.
Related Issue(s)
Verification
Documentation
docs-directory, Altinnpedia or a separate linked PR in altinn-studio-docs., if applicable)Summary by CodeRabbit
New Features
REVISION_SUFFIXfor improved tracking of deployment revisions.revisionSuffixparameter across various Bicep configuration files to enhance deployment customization and versioning.Chores