-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
vcf-validator: add linux-aarch64 build #51425
Conversation
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces modifications to the Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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 (
|
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: 1
🧹 Outside diff range and nitpick comments (3)
recipes/vcf-validator/build.sh (2)
3-4
: Approved: Enhanced debugging withset -x
The addition of
set -x
is beneficial for debugging purposes, as it will print each command before execution. This can be particularly useful for troubleshooting build issues.However, please be aware that this may produce verbose output and could potentially expose sensitive information in logs. Consider wrapping this command with a conditional statement to enable it only when needed, e.g.,
if [ "${DEBUG}" = "true" ]; then set -x; fi
.
11-11
: Approved: Optimized parallel build with${CPU_COUNT}
The modification to use
${CPU_COUNT}
instead of a hardcoded value for parallel builds is an excellent improvement. This change allows the build process to adapt to the available resources in different environments, potentially speeding up the build on systems with more cores.For added robustness, consider adding a fallback value:
make -j"${CPU_COUNT:-2}" || { echo "Build failed" >&2; exit 1; }This ensures that if
${CPU_COUNT}
is not set, the build will default to using 2 cores, maintaining the previous behavior.recipes/vcf-validator/meta.yaml (1)
Line range hint
2-2
: Update the package version to 0.10.1The version in the recipe (0.10.0) does not match the version mentioned in the PR summary (0.10.1). Please update the version to ensure consistency with the intended release.
Apply this change:
-{% set version = "0.10.0" %} +{% set version = "0.10.1" %}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- recipes/vcf-validator/build.sh (1 hunks)
- recipes/vcf-validator/meta.yaml (2 hunks)
🧰 Additional context used
🔇 Additional comments (4)
recipes/vcf-validator/build.sh (1)
Line range hint
1-20
: Overall: Improved build script with enhanced debugging and efficiencyThe changes to this build script are well-aligned with the PR objectives and represent good improvements:
- The addition of
set -x
enhances debugging capabilities, which can be crucial when troubleshooting build issues across different architectures.- The use of
${CPU_COUNT}
for parallel builds allows for better utilization of available resources, which is particularly beneficial when building for different architectures like linux-aarch64.These changes should contribute to a more robust and efficient build process for the vcf-validator package across different platforms, including the newly added linux-aarch64 architecture.
recipes/vcf-validator/meta.yaml (3)
13-13
: LGTM: Build number incrementThe build number has been correctly incremented from 0 to 1. This change is appropriate when updating the recipe without changing the upstream version.
49-49
: LGTM: Added linux-aarch64 platform supportThe addition of
linux-aarch64
to theadditional-platforms
list is consistent with the PR objectives. This change will enable builds for the linux-aarch64 architecture.To ensure the build works correctly for the new platform, please verify the build process specifically for linux-aarch64. You can use the following command to trigger a test build for this platform:
#!/bin/bash # Trigger a test build for the recipe on linux-aarch64 bioconda-utils build recipes/vcf-validator --docker --mulled-test --target-platform linux-aarch64
Line range hint
1-54
: Summary of reviewThe changes in this file generally align well with the PR objectives to add linux-aarch64 build support for the vcf-validator package. The build number increment, dependency updates, and addition of the linux-aarch64 platform are all appropriate changes.
However, there is one critical issue that needs to be addressed:
- The version number in the recipe (0.10.0) does not match the version mentioned in the PR summary (0.10.1). This discrepancy needs to be resolved before the PR can be approved.
Once the version number is updated and the suggested verifications are performed, this PR should be ready for approval.
After addressing the version discrepancy, please run a final verification build for all platforms:
#!/bin/bash # Trigger a test build for the recipe on all platforms bioconda-utils build recipes/vcf-validator --docker --mulled-test
host: | ||
- libboost-devel | ||
- libcurl | ||
- libtool | ||
- zstd | ||
- c-ares | ||
- libcurl | ||
- openssl | ||
- bzip2 | ||
- libzlib |
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
Issue Detected: Missing Installation of bioconda-utils
The build process fails because bioconda-utils
is not found. While several pipeline configurations reference installing bioconda-utils
, there are no actual installation commands present in the codebase. Ensure that bioconda-utils
is properly installed in the build environment to resolve the build failures.
🔗 Analysis chain
LGTM: Updated build and host dependencies
The changes to the build
and host
sections look good:
- Moving
libcurl
to thebuild
section is appropriate if it's only needed during the build process. - The addition of new build dependencies (
libtool
,zstd
,c-ares
,openssl
,bzip2
, andlibzlib
) provides a more comprehensive build environment.
These changes align with the PR objectives and should improve the build process for the linux-aarch64 platform.
To ensure these changes don't introduce any issues, please verify the build process for all supported platforms. You can use the following command to trigger a test build:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Trigger a test build for the recipe
bioconda-utils build recipes/vcf-validator
Length of output: 268
Script:
#!/bin/bash
# Check if 'bioconda-utils' is installed and available in PATH
which bioconda-utils
Length of output: 95
Script:
#!/bin/bash
# Search for occurrences of 'bioconda-utils' in the codebase
rg "bioconda-utils"
Length of output: 4719
Script:
#!/bin/bash
# Search for installation commands related to 'bioconda-utils' in the codebase
rg -i "install.*bioconda-utils"
Length of output: 516
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
🧹 Outside diff range and nitpick comments (3)
recipes/vcf-validator/build.sh (3)
3-4
: Consider making debug output conditional.The addition of
set -x
is helpful for troubleshooting build issues. However, it may produce verbose output in CI logs.Consider making this conditional, so it's only enabled when needed:
-set -x +if [ "${DEBUG_BUILD:-false}" = "true" ]; then + set -x +fiThis way, you can enable debugging by setting the
DEBUG_BUILD
environment variable without modifying the script.
8-14
: LGTM! Consider adding a comment for non-ARM architectures.The addition of ARM architecture handling is well-implemented and addresses a specific issue with unsigned char on these platforms.
Consider adding a comment in the
*)
case for clarity:case $(uname -m) in aarch64 | arm64) export CXXFLAGS="${CXXFLAGS} -funsigned-char" # .../vcf/compression.cpp:101:9: error: narrowing conversion of '-117' from 'int' to 'char' ;; *) + # No additional flags needed for other architectures ;; esac
19-19
: LGTM! Consider adding a fallback for CPU_COUNT.The use of
${CPU_COUNT}
instead of a hardcoded value is an excellent improvement. It allows the build to utilize all available CPU cores, potentially speeding up the build process significantly.Consider adding a fallback value in case
CPU_COUNT
is not set:-make -j"${CPU_COUNT}" || { echo "Build failed" >&2; exit 1; } +make -j"${CPU_COUNT:-2}" || { echo "Build failed" >&2; exit 1; }This ensures that if
CPU_COUNT
is not set for some reason, the build will still proceed with a reasonable default value.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- recipes/vcf-validator/build.sh (1 hunks)
🧰 Additional context used
🔇 Additional comments (1)
recipes/vcf-validator/build.sh (1)
18-18
: LGTM! Proper propagation of CXXFLAGS to cmake.The addition of
-DCMAKE_CXX_FLAGS="${CXXFLAGS}"
to the cmake command ensures that all compiler flags, including those set for specific architectures, are properly passed to the build system. This is a good practice for maintaining consistency.
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
e3e31a0
to
0d1945d
Compare
@BiocondaBot please fetch artifacts |
Package(s) built are ready for inspection:
Docker image(s) built:
|
LGTM! |
@BiocondaBot please add label |
Describe your pull request here
Please read the guidelines for Bioconda recipes before opening a pull request (PR).
General instructions
@BiocondaBot please add label
command.@bioconda/core
in a comment.Instructions for avoiding API, ABI, and CLI breakage issues
Conda is able to record and lock (a.k.a. pin) dependency versions used at build time of other recipes.
This way, one can avoid that expectations of a downstream recipe with regards to API, ABI, or CLI are violated by later changes in the recipe.
If not already present in the meta.yaml, make sure to specify
run_exports
(see here for the rationale and comprehensive explanation).Add a
run_exports
section like this:with
...
being one of:{{ pin_subpackage("myrecipe", max_pin="x") }}
{{ pin_subpackage("myrecipe", max_pin="x.x") }}
{{ pin_subpackage("myrecipe", max_pin="x.x") }}
(in such a case, please add a note that shortly mentions your evidence for that){{ pin_subpackage("myrecipe", max_pin="x.x.x") }}
(in such a case, please add a note that shortly mentions your evidence for that){{ pin_subpackage("myrecipe", max_pin=None) }}
while replacing
"myrecipe"
with eithername
if aname|lower
variable is defined in your recipe or with the lowercase name of the package in quotes.Bot commands for PR management
Please use the following BiocondaBot commands:
Everyone has access to the following BiocondaBot commands, which can be given in a comment:
@BiocondaBot please update
@BiocondaBot please add label
please review & merge
label.@BiocondaBot please fetch artifacts
You can use this to test packages locally.
Note that the
@BiocondaBot please merge
command is now depreciated. Please just squash and merge instead.Also, the bot watches for comments from non-members that include
@bioconda/<team>
and will automatically re-post them to notify the addressed<team>
.