ci: add conda build and release workflows#3
Conversation
Summary of ChangesHello @Luohaothu, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the project's continuous integration and deployment capabilities for Conda packages. It introduces automated workflows for building and testing Conda recipes on every code change, and establishes a streamlined process for releasing packages upon new version publication. These changes improve reliability and efficiency in package distribution. Highlights
Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Warning Rate limit exceeded
⌛ 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. 📝 WalkthroughWalkthroughTwo GitHub Actions workflows are introduced to automate Conda package building and distribution. The CI workflow triggers on pull requests and pushes to master, building and testing packages on Ubuntu and macOS. The release workflow triggers on published releases, performing similar build and test steps, then uploading the final package to Anaconda Cloud. Changes
Sequence Diagram(s)sequenceDiagram
participant GitHub as GitHub Actions
participant Miniconda as Miniconda Setup
participant Git as Git Tags
participant CondaBuild as Conda Build
participant Testing as Package Tests
GitHub->>Miniconda: Set up Miniconda + Mamba
Miniconda->>Miniconda: Install conda-build & anaconda-client
Miniconda-->>GitHub: Ready
GitHub->>Git: Resolve latest git tag
Git-->>GitHub: Tag resolved
GitHub->>CondaBuild: Build package from conda/recipe
CondaBuild-->>GitHub: Package built
GitHub->>Testing: Test built package
Testing-->>GitHub: Tests passed
sequenceDiagram
participant Release as Release Event
participant GitHub as GitHub Actions
participant Miniconda as Miniconda Setup
participant CondaBuild as Conda Build
participant Testing as Package Tests
participant Anaconda as Anaconda Cloud
Release->>GitHub: Trigger on publish
GitHub->>Miniconda: Set up Miniconda + Mamba
Miniconda->>Miniconda: Install conda-build & anaconda-client
Miniconda-->>GitHub: Ready
GitHub->>CondaBuild: Build package from conda/recipe
CondaBuild-->>GitHub: Package built
GitHub->>Testing: Test built package
Testing-->>GitHub: Tests passed
GitHub->>Anaconda: Upload package using token
Anaconda-->>GitHub: Upload complete
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
已查看评审信息：当前仅有 Gemini Code Assist 的自动化摘要，未发现需要修正的人工评审意见。我已按需求补齐 PR/CI/Release 流程与上传 secret 说明。 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces Conda build infrastructure by adding a build script and updating the Conda recipe. The changes are a good step towards packaging the project with Conda. My review focuses on improving the robustness and maintainability of the build script to align with Conda best practices, ensuring it works reliably both within the conda-build environment and for local testing.
conda/recipe/build.sh
Outdated
| cmake -S "$SRC_DIR" \ | ||
| -B "$BUILD_DIR" \ | ||
| -DCMAKE_BUILD_TYPE=Release \ | ||
| -DCMAKE_INSTALL_PREFIX="$PREFIX" \ | ||
| -DAMGCL_BUILD_TESTS=OFF \ | ||
| -DAMGCL_BUILD_EXAMPLES=OFF |
There was a problem hiding this comment.
This cmake command can be improved for robustness and adherence to conda-build best practices:
- Use
CMAKE_ARGS: It's recommended to include${CMAKE_ARGS}in yourcmakecall.conda-buildpopulates this variable with essential arguments, such as toolchain configurations and the installation prefix (-DCMAKE_INSTALL_PREFIX=$PREFIX). This ensures your build is portable and correctly configured within the conda environment. - Local build support: When running this script locally,
$SRC_DIRwill be unset.cmake -S "$SRC_DIR"would result incmake -S "", which is likely not what you intend. Using"${SRC_DIR:-.}"provides a fallback to the current directory, making the script work correctly for local testing from the project root.
By incorporating these changes, the build script will be more robust for both conda builds and local execution.
| cmake -S "$SRC_DIR" \ | |
| -B "$BUILD_DIR" \ | |
| -DCMAKE_BUILD_TYPE=Release \ | |
| -DCMAKE_INSTALL_PREFIX="$PREFIX" \ | |
| -DAMGCL_BUILD_TESTS=OFF \ | |
| -DAMGCL_BUILD_EXAMPLES=OFF | |
| cmake -S "${SRC_DIR:-.}" \ | |
| -B "$BUILD_DIR" \ | |
| ${CMAKE_ARGS} \ | |
| -DCMAKE_BUILD_TYPE=Release \ | |
| -DAMGCL_BUILD_TESTS=OFF \ | |
| -DAMGCL_BUILD_EXAMPLES=OFF |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3d1ea960fa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| shell: bash -el {0} | ||
| run: | | ||
| set -euo pipefail | ||
| PKG_FILE="$(conda build --output conda/recipe)" |
There was a problem hiding this comment.
The upload step calls conda build --output conda/recipe, but unlike the build/test steps it does not set GIT_DESCRIBE_TAG. Since conda/recipe/meta.yaml uses environ['GIT_DESCRIBE_TAG'] to compute the package version, this command fails in the upload step on every release run, preventing package publication.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.github/workflows/conda-release.yml:
- Around line 66-74: The upload step's run block invokes `conda build --output
conda/recipe` but doesn't export GIT_DESCRIBE_TAG so meta.yaml cannot resolve
and the PKG_FILE path fails; update that GitHub Actions step to include the same
env entry for GIT_DESCRIBE_TAG (set from the existing GIT_DESCRIBE_TAG input or
computed value used earlier) so the `conda build --output conda/recipe` command
can read GIT_DESCRIBE_TAG when computing the package path.
- Around line 33-43: The Resolve release tag step (id: resolve_tag) currently
interpolates ${{ github.event.release.tag_name }} directly in the run script
which risks pre-run shell injection; change the step to pass the release tag via
an environment variable (e.g., env: RELEASE_TAG: ${{
github.event.release.tag_name }}) and in the run block assign TAG="$RELEASE_TAG"
(properly quoted) before using it (keep set -euo pipefail and the echo to
GITHUB_OUTPUT). This ensures the tag value is not expanded into the shell script
text and prevents injection while preserving the existing behavior.
In `@conda/recipe/build.sh`:
- Around line 13-14: The cmake invocation uses an unguarded $SRC_DIR which will
trigger "unbound variable" under set -u; change the cmake -S argument to use the
same fallback as earlier (use ${SRC_DIR:-${PWD}}) so cmake -S receives a valid
path even when SRC_DIR is unset, and leave -B "$BUILD_DIR" as-is (referencing
the cmake invocation and variables SRC_DIR and BUILD_DIR).
🧹 Nitpick comments (2)
.github/workflows/conda-ci.yml (1)
37-47: CI will fail on PRs to repos with no tags — consider a fallback for PR builds.The
Resolve release tagstep hard-fails if no git tag exists (Line 45-46). This is fine for release workflows, but for CI on pull requests, it means the workflow is unusable until the first tag is created. Consider using a fallback version (e.g.,0.0.0) for PR builds so CI can validate the build even before the first release.Suggested approach
TAG="$(git describe --tags --abbrev=0 2>/dev/null || true)" if [ -z "$TAG" ]; then - echo "No git tag found. At least one tag is required for recipe versioning." - exit 1 + echo "No git tag found; using fallback version for CI." + TAG="v0.0.0" fi echo "tag=$TAG" >> "$GITHUB_OUTPUT".github/workflows/conda-release.yml (1)
60-61: Redundantifcondition — this workflow only triggers onreleaseevents.The
if: github.event_name == 'release'guard on Line 61 is always true since the workflow'son:trigger is exclusivelyrelease. It's harmless but adds no value. Could be removed for clarity, or kept as a safety net if you plan to add more triggers later.
|
已处理评审意见：
关联提交： |
|
已按你的要求更新：发布 workflow 的默认 Anaconda org 已从 修改文件： 已推送到当前 PR 分支（commit: |
|
按你的更新，已将发布 workflow 的默认 Anaconda 组织名改为全小写 修改文件： 最新 commit： |
|
按你的要求，已去掉 对应 commit： |
|
我按你说的保留原始风格，已把
对应 commit: |
|
按你的意见， 最新 commit： 这样后续这文件在 PR 中保持稳定。 |
|
已按你的要求处理： 如你要“彻底回到 PR 前状态（包含 workflow 等全部改动回滚）”，我可以另起一次提交把 PR 范围也清空，但你现在这条只涉及 |
|
已确认并处理：当前分支与 新增差异现在仅为：
对应 commit: |
1 participant
Summary
masterPR and push.build.shexplicitly to configure, build, and install headers/CMake artifacts into the conda prefix.Validation
bash -n conda/recipe/build.shpython - <<'PY'withyaml.safe_loadfor both workflow files.Notes
ANACONDA_API_TOKEN.ANACONDA_ORGcan override target Anaconda organization (defaults toOpflowDev).Summary by CodeRabbit