Backport PR #2744 to release/v1.7 for use ci-container for update deps cron job #2748
Conversation
Signed-off-by: vankichi <[email protected]>
Deploying vald with
|
| Latest commit: |
0cc6996
|
| Status: | ⚡️ Build in progress... |
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request modifies the GitHub Actions workflow file Changes
Possibly related PRs
Suggested labels
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 (
|
|
[CHATOPS:HELP] ChatOps commands.
|
![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 (1)
.github/workflows/update-deps.yaml (1)
Line range hint
75-82: Fix the shell script syntax in version comparisonThe version comparison logic contains a syntax error and might not work as expected.
Apply this fix:
- if ${LATEST} eq "1.7"; then + if [ "${LATEST}" = "1.7" ]; thenAlso, consider using a more robust version comparison:
- SUPPORT=$(echo ${LATEST} | awk '{print $1-0.1}') + SUPPORT=$(echo "${LATEST}" | awk -F. '{printf "%.1f", $1"."$2-0.1}')
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/update-deps.yaml(2 hunks)
🔇 Additional comments (3)
.github/workflows/update-deps.yaml (3)
57-58: Clarify the necessity of the license command
The comment suggests uncertainty about whether make license should be removed. Since this is a backport PR, we should maintain consistency with the source PR #2744.
#!/bin/bash
# Description: Check if the source PR (#2744) retained or removed the license command
# Expected: Should match the decision made in the source PR
gh pr view 2744 --json files \
--jq '.files[] | select(.path == ".github/workflows/update-deps.yaml") | .patch' \
| grep -A 5 -B 5 "make license"27-28: Verify the referenced workflow file exists
The job references a reusable workflow file _detect-ci-container.yaml. Let's ensure this file exists and is properly configured.
✅ Verification successful
Referenced workflow file exists and is properly configured
The reusable workflow _detect-ci-container.yaml exists and contains a valid workflow definition that:
- Accepts workflow calls and provides an output named
TAG - Uses appropriate actions to determine and detect Docker image tags
- Follows proper GitHub Actions syntax and conventions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the referenced workflow file exists
# Expected: File should exist and contain valid workflow definition
if [ -f ".github/workflows/_detect-ci-container.yaml" ]; then
echo "File exists. Checking content..."
cat ".github/workflows/_detect-ci-container.yaml"
else
echo "ERROR: Referenced workflow file does not exist!"
fi
Length of output: 1861
31-33: LGTM! Container configuration looks correct.
The job dependency and container configuration are properly set up. The container image uses the GitHub Container Registry format and dynamically sets the tag from the detect-ci-container job output.
✅ Verification successful
Container configuration is correctly implemented and widely used
The container configuration is properly set up:
- The
detect-ci-containerreusable workflow determines the appropriate container tag - The container image
ghcr.io/vdaas/vald/vald-ci-containeris consistently used across multiple workflows - The tag is dynamically obtained through the workflow's outputs using proper job dependencies
- The pattern is well-established and standardized across the repository's workflows
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the container image exists in GitHub Container Registry
# Expected: Container image should exist with recent tags
gh api \
-H "Accept: application/vnd.github+json" \
"/orgs/vdaas/packages/container/vald-ci-container/versions" \
--jq '.[0:5] | .[] | {created_at: .created_at, tags: .metadata.container.tags}'
Length of output: 237
Script:
#!/bin/bash
# Let's verify the container image existence using a different approach
# First, check if the workflow file exists and its content
cat .github/workflows/update-deps.yaml
# Then check for any related container configuration in other workflow files
fd -e yaml -e yml . .github/workflows/ --exec grep -l "ghcr.io/vdaas/vald/vald-ci-container" {}
Length of output: 4166
Script:
#!/bin/bash
# Let's check the detect-ci-container workflow that provides the TAG
cat .github/workflows/_detect-ci-container.yaml
# Also check one of the other workflows using this container to understand the pattern
cat .github/workflows/unit-test.yaml
Length of output: 5116
…e-ci-container-for-update-deps
kpango
deleted the
backport/release/v1.7/ci/workflow/use-ci-container-for-update-deps
branch
Description
SSIA
Related Issue
Versions
Checklist
Special notes for your reviewer
Summary by CodeRabbit
New Features
Improvements
These changes streamline the update process and improve the overall efficiency of the CI workflow.