-
Notifications
You must be signed in to change notification settings - Fork 3
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
ci: ensure we store the versions as gh variables #1405
Conversation
📝 WalkthroughWalkthroughThe changes involve significant updates to CI/CD workflow configurations across multiple environments, including production, staging, and YT01. Key modifications include the refactoring of jobs such as 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
|
Quality Gate passedIssues Measures |
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.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
.github/workflows/workflow-store-github-env-variable.yml (1)
28-31
: Consider removing unnecessary checkout step.The workflow doesn't appear to use any repository content. The checkout step could be removed to improve workflow execution time.
.github/workflows/ci-cd-staging.yml (1)
100-105
: LGTM - Consistent implementation with store-infra-version.The implementation maintains consistency with the infra version storage pattern, which is good for maintainability.
Consider combining both version storage operations into a single job with multiple steps to reduce workflow execution time and complexity. This could be achieved by:
- Creating a new reusable workflow that handles both variables
- Using job outputs to pass both version values
- Executing the storage operations in parallel within the same job
Example structure:
store-versions: needs: [deploy-infra, deploy-apps, get-current-version] if: ${{ needs.deploy-infra.result == 'success' && needs.deploy-apps.result == 'success' }} uses: ./.github/workflows/workflow-store-github-env-variables.yml with: variables: | LATEST_DEPLOYED_INFRA_VERSION=${{ needs.get-current-version.outputs.version }} LATEST_DEPLOYED_APPS_VERSION=${{ needs.get-current-version.outputs.version }} environment: staging.github/workflows/ci-cd-prod.yml (1)
74-79
: LGTM! Well-structured version storage for infrastructure deployments.The implementation correctly uses the reusable workflow pattern to store infrastructure versions, with proper environment isolation and secure token handling.
Consider adding a comment explaining the purpose of
RELEASE_VERSION_STORAGE_PAT
and its required permissions for future maintainers.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (4)
.github/workflows/ci-cd-prod.yml
(2 hunks).github/workflows/ci-cd-staging.yml
(2 hunks).github/workflows/ci-cd-yt01.yml
(2 hunks).github/workflows/workflow-store-github-env-variable.yml
(1 hunks)
🔇 Additional comments (7)
.github/workflows/workflow-store-github-env-variable.yml (3)
1-4
: LGTM! Well-structured workflow definition.
The workflow name is descriptive and the trigger configuration is appropriate for a reusable workflow.
23-27
: LGTM! Proper job configuration.
The job configuration follows best practices with latest runner and proper environment handling.
5-21
: Consider adding input validation and explicit token permissions.
While the input and secret definitions are well-documented, consider these security enhancements:
- Add explicit permissions required for the GH_TOKEN in the description (e.g., "write:variables")
- Consider validating the variable_name format to prevent injection attempts
Let's check if there are any existing variable name validations in the codebase:
.github/workflows/ci-cd-yt01.yml (2)
66-71
: LGTM! Well-structured refactor of the infrastructure version storage.
The change effectively utilizes the reusable workflow pattern, maintaining proper job dependencies while simplifying the version storage process.
102-107
: LGTM! Well-structured refactor of the apps version storage.
The change mirrors the infrastructure version storage pattern, ensuring consistency and reducing code duplication through the use of the reusable workflow.
.github/workflows/ci-cd-prod.yml (2)
134-139
: LGTM! Consistent implementation for storing application versions.
The implementation maintains consistency with the infrastructure version storage pattern, ensuring a unified approach across the workflow.
Line range hint 74-139
: Verify the reusable workflow implementation.
Let's verify the existence and implementation of the referenced reusable workflow.
✅ Verification successful
Reusable workflow implementation is correctly referenced and properly implemented
The workflow .github/workflows/workflow-store-github-env-variable.yml
exists and implements all the required functionality:
- Accepts required inputs:
variable_name
,variable_value
, andenvironment
- Requires the necessary
GH_TOKEN
secret - Uses the GitHub CLI to set environment variables with proper scoping
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the reusable workflow exists and check its implementation
echo "Checking for workflow-store-github-env-variable.yml..."
if [ -f ".github/workflows/workflow-store-github-env-variable.yml" ]; then
echo "Found workflow file. Checking implementation..."
cat ".github/workflows/workflow-store-github-env-variable.yml"
else
echo "ERROR: Referenced workflow file not found!"
# List available workflow files for reference
echo "Available workflow files:"
find .github/workflows -type f -name "*.yml"
fi
Length of output: 1431
- name: Set GitHub variable | ||
env: | ||
GH_TOKEN: ${{ secrets.GH_TOKEN }} | ||
run: | | ||
gh variable set ${{ inputs.variable_name }} \ | ||
--body "${{ inputs.variable_value }}" \ | ||
--env ${{ inputs.environment }} \ | ||
--repo ${{ github.repository }} |
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.
🛠️ Refactor suggestion
Add error handling and validation.
The current implementation could benefit from these improvements:
- Add error handling for the gh CLI command
- Validate that the variable was set successfully
Consider this enhanced implementation:
- name: Set GitHub variable
env:
GH_TOKEN: ${{ secrets.GH_TOKEN }}
run: |
+ if ! command -v gh &> /dev/null; then
+ echo "Error: GitHub CLI not found"
+ exit 1
+ fi
+
gh variable set ${{ inputs.variable_name }} \
--body "${{ inputs.variable_value }}" \
--env ${{ inputs.environment }} \
--repo ${{ github.repository }}
+
+ # Verify the variable was set
+ if ! gh variable list --env ${{ inputs.environment }} | grep -q "^${{ inputs.variable_name }} "
+ then
+ echo "Error: Failed to verify variable was set"
+ exit 1
+ fi
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
- name: Set GitHub variable | |
env: | |
GH_TOKEN: ${{ secrets.GH_TOKEN }} | |
run: | | |
gh variable set ${{ inputs.variable_name }} \ | |
--body "${{ inputs.variable_value }}" \ | |
--env ${{ inputs.environment }} \ | |
--repo ${{ github.repository }} | |
- name: Set GitHub variable | |
env: | |
GH_TOKEN: ${{ secrets.GH_TOKEN }} | |
run: | | |
if ! command -v gh &> /dev/null; then | |
echo "Error: GitHub CLI not found" | |
exit 1 | |
fi | |
gh variable set ${{ inputs.variable_name }} \ | |
--body "${{ inputs.variable_value }}" \ | |
--env ${{ inputs.environment }} \ | |
--repo ${{ github.repository }} | |
# Verify the variable was set | |
if ! gh variable list --env ${{ inputs.environment }} | grep -q "^${{ inputs.variable_name }} " | |
then | |
echo "Error: Failed to verify variable was set" | |
exit 1 | |
fi |
uses: ./.github/workflows/workflow-store-github-env-variable.yml | ||
with: | ||
variable_name: LATEST_DEPLOYED_INFRA_VERSION | ||
variable_value: ${{ needs.get-current-version.outputs.version }} | ||
environment: staging | ||
secrets: |
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.
💡 Codebase verification
Workflow improvements needed for better reliability
The reusable workflow lacks timeout configuration and explicit error handling. While environment protection is in place for staging (with branch policies), the workflow could be more robust.
- Add
timeout-minutes
to thestore-variable
job in.github/workflows/workflow-store-github-env-variable.yml
- Consider adding error handling by wrapping the variable set command in a conditional check
- The current implementation correctly uses environment contexts and required inputs
Example fix for the reusable workflow:
jobs:
store-variable:
timeout-minutes: 5 # Prevent hanging jobs
name: Store GitHub Environment Variable
runs-on: ubuntu-latest
environment: ${{ inputs.environment }}
🔗 Analysis chain
LGTM with suggestions for enhanced reliability.
The transition to a reusable workflow for storing GitHub variables is a good improvement for maintainability.
Consider these enhancements:
- Add a timeout to prevent hanging jobs:
timeout-minutes: 5
- Add error handling by checking the workflow status in downstream jobs
- Verify environment protection rules are in place for the staging environment variables
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify environment protection rules for staging
gh api -H "Accept: application/vnd.github+json" \
/repos/digdir/dialogporten/environments/staging \
--jq '.protection_rules[]'
Length of output: 195
Script:
#!/bin/bash
# Get more details about the branch protection rules
gh api -H "Accept: application/vnd.github+json" \
/repos/digdir/dialogporten/environments/staging \
--jq '.'
Length of output: 629
Script:
#!/bin/bash
# Check the reusable workflow for timeout and error handling
cat .github/workflows/workflow-store-github-env-variable.yml
Length of output: 1137
Script:
#!/bin/bash
# Check if there are any other jobs depending on store-infra-version
rg "needs.*store-infra-version" .github/workflows/ -A 5
Length of output: 57
Description
Related Issue(s)
Fixes issues in the current workflow regarding missing .git-directory https://github.com/digdir/dialogporten/actions/runs/11686732981/job/32543782272
Verification
Documentation
docs
-directory, Altinnpedia or a separate linked PR in altinn-studio-docs., if applicable)Summary by CodeRabbit
New Features
Bug Fixes
Documentation