-
Notifications
You must be signed in to change notification settings - Fork 150
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
chore(dockerfile): clone and build correct instance-manager codes #1342
Conversation
Warning Rate limit exceeded@derekbit has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 21 minutes and 7 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThe pull request modifies the Changes
The changes are minimal and focused on build configuration flexibility, with no significant alterations to the overall Dockerfile structure or build logic. 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
|
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: 0
🧹 Nitpick comments (2)
Dockerfile.dapper (2)
19-19
: Consider using a more specific default branch valueSetting the default branch to "master" might be problematic:
- Some repositories use "main" as the default branch
- Using a specific version/tag would be more reliable for reproducible builds
Consider one of these approaches:
- Use a specific version tag as default
- Make it a required build argument instead of an ENV with default value
-ENV LONGHORN_INSTANCE_MANAGER_BRANCH="master" +ARG LONGHORN_INSTANCE_MANAGER_VERSION +ENV LONGHORN_INSTANCE_MANAGER_VERSION=${LONGHORN_INSTANCE_MANAGER_VERSION}
19-19
: Documentation and testing recommendationsSince this change affects the build process, please consider:
- Updating the build documentation to reflect the new configurable branch
- Adding examples in the README for common use cases
- Ensuring CI/CD pipelines are updated if they need to specify a different branch
Would you like me to help draft the documentation updates?
Also applies to: 100-102
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Dockerfile.dapper
(2 hunks)
🔇 Additional comments (1)
Dockerfile.dapper (1)
100-102
: Verify the instance-manager build process
The implementation looks correct, but let's ensure:
- The branch/version exists in the repository
- The build process is consistent with other Longhorn components
Let's verify the repository and its branches:
✅ Verification successful
Let's gather more information about the build process to ensure consistency:
Build configuration is consistent and branch exists
The verification confirms:
- The
LONGHORN_INSTANCE_MANAGER_BRANCH
is properly defined as "master" in Dockerfile.dapper, and the branch exists in the repository - The build flags
-tags netgo -ldflags
are consistent with other Longhorn components' build patterns - The static linking approach with
-linkmode external -extldflags -static
ensures proper binary portability
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the repository exists and list available branches/tags
gh repo view longhorn/longhorn-instance-manager --json defaultBranch,name,description
gh api repos/longhorn/longhorn-instance-manager/branches --jq '.[].name'
Length of output: 1474
Script:
#!/bin/bash
# Check the Dockerfile.dapper files in other Longhorn components for build patterns
echo "=== Checking build patterns in other components ==="
fd Dockerfile.dapper --type f --exec sh -c 'echo "\nFile: {}"; grep -A 5 "go build" {}'
# Check the variable definition
echo -e "\n=== Checking LONGHORN_INSTANCE_MANAGER_BRANCH variable ==="
grep -r "LONGHORN_INSTANCE_MANAGER_BRANCH" .
# Check if there are any other build flags or patterns
echo -e "\n=== Checking other Go build patterns ==="
rg "go build.*-ldflags" -A 2
Length of output: 1124
Signed-off-by: Derek Su <derek.su@suse.com>
Which issue(s) this PR fixes:
Issue #
What this PR does / why we need it:
Special notes for your reviewer:
Additional documentation or context