fix: added dependency on argo action #2798
Conversation
|
WalkthroughThe changes introduce a new GitHub Actions workflow titled "New Database Operations" in the 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
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
.github/workflows/db-ops.yaml (3)
Line range hint
9-13: Consider simplifying the SHORT_HASH environment variable logic.The nested ternary operators make the SHORT_HASH logic hard to read and maintain. Consider using a more explicit approach with GitHub Actions expressions.
- SHORT_HASH: ${{ github.event.client_payload.environment == 'prod' && vars.PROD_WF_SHORT_SHA || github.event.client_payload.environment == 'sb' && vars.SB_WF_SHORT_SHA || vars.DEV_WF_SHORT_SHA }} + SHORT_HASH: ${{ + github.event.client_payload.environment == 'prod' && vars.PROD_WF_SHORT_SHA || + github.event.client_payload.environment == 'sb' && vars.SB_WF_SHORT_SHA || + vars.DEV_WF_SHORT_SHA + }}🧰 Tools
🪛 actionlint
146-146: receiver of object dereference "migration_env" must be type of object but got "string"
(expression)
Line range hint
143-162: Fix environment variable references and add timeout for ArgoCD sync.There are several issues in the ArgoCD sync job:
- The environment reference is incorrect
- Missing timeout for the sync operation which is crucial for database operations
Apply these fixes:
needs: update-helm-chart if: ${{ needs.update-helm-chart.result == 'success' }} runs-on: ubuntu-latest - environment: ${{ github.env.MIGRATION_ENV }} + environment: ${{ env.MIGRATION_ENV }} env: - stage: ${{ github.env.MIGRATION_ENV }} + stage: ${{ env.MIGRATION_ENV }} permissions: contents: read steps: - name: Checkout uses: actions/checkout@v3 - name: Run ArgoCD Action id: argocd_api uses: ./.github/actions/argocd-action + timeout-minutes: 10 with: argocd_username: ${{ secrets.ARGOCD_USERNAME }} argocd_password: ${{ secrets.ARGOCD_PASSWORD }} argocd_server: ${{ secrets.ARGOCD_SERVER }} tg_svc_key: ${{ secrets.TWINGATE_SERVICE_KEY_SECRET_NAME }}🧰 Tools
🪛 actionlint
146-146: receiver of object dereference "migration_env" must be type of object but got "string"
(expression)
Line range hint
164-182: Enhance Slack notification job dependencies and message.The Slack notification should include the complete deployment status:
- Add dependency on the ArgoCD sync job
- Include ArgoCD sync status in the message
Apply these changes:
send-to-slack: runs-on: ubuntu-latest - needs: [update-helm-chart,build-and-push-ee-image] + needs: [update-helm-chart,build-and-push-ee-image,sync-argo-app] if: ${{ needs.update-helm-chart.result == 'success' }} permissions: contents: read packages: write steps: - name: Send alert to Slack channel id: slack uses: slackapi/slack-github-action@v1.26.0 with: channel-id: '${{ secrets.ARGO_SLACK_CHANNEL_ID }}' - slack-message: "Wf-service Migrations in ${{ env.MIGRATION_ENV }} with tag: ${{ env.SHORT_HASH }}-${{ needs.build-and-push-ee-image.outputs.SUBMODULE_SHORT_HASH }}-${{ env.MIGRATION_ENV }} and build result: ${{ job.status }}. successfully updated the wf-service migration jobs helm values for ${{ env.MIGRATION_ENV }}." + slack-message: "Wf-service Migrations in ${{ env.MIGRATION_ENV }} with tag: ${{ env.SHORT_HASH }}-${{ needs.build-and-push-ee-image.outputs.SUBMODULE_SHORT_HASH }}-${{ env.MIGRATION_ENV }}. Status: Build=${{ needs.build-and-push-ee-image.result }}, Helm=${{ needs.update-helm-chart.result }}, ArgoCD=${{ needs.sync-argo-app.result }}"🧰 Tools
🪛 actionlint
146-146: receiver of object dereference "migration_env" must be type of object but got "string"
(expression)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- .github/workflows/db-ops.yaml (1 hunks)
🔇 Additional comments (3)
.github/workflows/db-ops.yaml (3)
Line range hint
18-89: LGTM! The build job follows Docker best practices.The implementation includes proper layer caching, multi-arch support, and secure credential handling.
🧰 Tools
🪛 actionlint
146-146: receiver of object dereference "migration_env" must be type of object but got "string"
(expression)
Line range hint
91-142: LGTM! The Helm chart update implementation is robust.The job correctly handles environment-specific configurations and uses sparse checkout for efficiency.
🧰 Tools
🪛 actionlint
146-146: receiver of object dereference "migration_env" must be type of object but got "string"
(expression)
Line range hint
1-182: Verify similar database operation workflows.Let's ensure there are no conflicting workflows for database operations.
✅ Verification successful
Based on the results, only one workflow file (.github/workflows/db-ops.yaml) contains the "run-test-migration" trigger, which is good as it prevents potential conflicts. However, let's verify if there are any other database-related operations in other workflow files to be completely certain.
Let's examine the database-related operations in the other two files to ensure there are no conflicting operations.
No conflicting database operations found across workflows
After analyzing the workflows, I can confirm that:
db-ops.yamlis the only workflow that handles therun-test-migrationtriggerpublish-workflows-service.ymlanddeploy-wf-service.ymlonly update image tags in Helm charts for database-related components but don't trigger actual database operations- The workflows are complementary rather than conflicting, with clear separation of concerns:
db-ops.yaml: Handles test migrationspublish-workflows-service.yml: Handles publishing workflow service imagesdeploy-wf-service.yml: Handles deployment configurations🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for similar database operation workflows # Expected: No other workflows should handle database migrations to avoid conflicts echo "Searching for other database operation workflows..." rg -l --type yaml "run-test-migration" .github/workflows/Length of output: 200
Script:
#!/bin/bash # Search for database-related keywords in workflow files echo "Searching for database-related operations in workflows..." rg -l --type yaml -e "prisma|database|migration|db-|dbMigrate" .github/workflows/Length of output: 326
Script:
#!/bin/bash # Check the context of database operations in the other workflow files echo "Checking publish-workflows-service.yml..." rg -A 5 -B 5 -e "prisma|database|migration|db-|dbMigrate" .github/workflows/publish-workflows-service.yml echo -e "\nChecking deploy-wf-service.yml..." rg -A 5 -B 5 -e "prisma|database|migration|db-|dbMigrate" .github/workflows/deploy-wf-service.ymlLength of output: 4770
🧰 Tools
🪛 actionlint
146-146: receiver of object dereference "migration_env" must be type of object but got "string"
(expression)
Summary by CodeRabbit
New Features
Improvements