feat: add release-driven conda publish workflow

[Luohaothu]

Summary

• add a release-triggered GitHub Actions workflow to build all conda variants
• derive package version from release tag and pass it into conda build
• upload built artifacts to Anaconda user channel opflow-dev using ANACONDA_API_TOKEN

Test Plan

• validated git diff and workflow file content locally
• actionlint is not available in this environment

Summary by CodeRabbit

• New Features

  • Packages are now available on Anaconda for each release.

• Chores

  • Updated conda recipe and release configuration to support dynamic versioning across multiple build variants.

[gemini-code-assist]

Summary of Changes

Hello @Luohaothu, I'm Gemini Code Assist¹! 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 establishes an automated, release-driven process for building and publishing hypre Conda packages. By integrating a GitHub Actions workflow, it streamlines the distribution pipeline, ensuring that new releases are promptly available on Anaconda with their correct versions, thereby enhancing maintainability and reducing manual effort.

Highlights

• Automated Conda Publishing: A new GitHub Actions workflow has been introduced to automate the building and publishing of Conda packages for hypre upon new releases.
• Dynamic Versioning: The Conda package version is now dynamically derived from the release tag, ensuring consistency between the release and the published package.
• Anaconda Upload: Built artifacts will be automatically uploaded to the Anaconda user channel opflow-dev using a secure API token.

Changelog

• conda-recipe/meta.yaml
  • Modified the package version to be set dynamically from an environment variable HYPRE_VERSION, defaulting to 3.1.0 if not provided.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/conda-release.yml

Activity

• The author validated the git diff and workflow file content locally.
• The author noted that actionlint was not available in their environment for validation.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

Warning

Rate limit exceeded

@Luohaothu has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 17 minutes and 56 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.

📝 Walkthrough

Walkthrough

A new GitHub Actions workflow automates publishing conda packages across multiple operating systems and MPI configurations upon release publication. The conda recipe configuration is updated to accept dynamic package versioning through environment variable templating.

Changes

Cohort / File(s)	Summary
Conda Release Automation .github/workflows/conda-release.yml, conda-recipe/meta.yaml	Introduces new CI/CD workflow for conda package publishing with matrix builds across OS/MPI variants and version resolution. Updates recipe to support templated versioning via HYPRE_VERSION environment variable with fallback default.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Release
    participant WF as Workflow Runner
    participant Build as Build Environment
    participant Conda as Conda-Build
    participant Anaconda as Anaconda Registry
    
    GH->>WF: Trigger on release published
    WF->>WF: Resolve version from release tag
    WF->>Build: Setup Miniconda & tooling
    Build->>Conda: Build conda packages (matrix: OS × MPI × OpenMP)
    Conda->>Conda: Generate artifacts
    Build->>WF: Collect built packages
    WF->>WF: Validate packages exist
    WF->>Anaconda: Upload to opflow-dev channel
    Anaconda-->>WF: Confirm upload success

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Add conda recipe variant matrix for hypre #1 — Both PRs modify conda-recipe/meta.yaml to manage package versioning configuration

Poem

🐰 The workflow hops, the packages build,
Across OS lands both wild and mild!
With MPI flavors, OpenMP delight,
Anaconda channels gleam so bright—
Release automation, fluffy and tight! 🚀

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat: add release-driven conda publish workflow' directly summarizes the main change - introducing a new GitHub Actions workflow for publishing conda packages triggered by releases.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into master

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch codex/release-conda-publish

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

The pull request updates the Conda recipe to support dynamic versioning via the HYPRE_VERSION environment variable, which is a necessary step for the proposed release-driven workflow. However, the GitHub Actions workflow file described in the PR title and description is missing from the changes. This is a significant omission as the workflow contains the core logic for triggering builds and publishing artifacts. I have also suggested a minor refinement to the version string handling in meta.yaml to improve robustness against common git tagging conventions and empty environment variables.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8c535b21ce

ℹ️ 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".

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @.github/workflows/conda-release.yml:
- Around line 70-78: The generated JSON for the conda-build --variants flag uses
strings instead of arrays; update the variant_json construction (the printf that
sets variant_json) so that mpi and openmp values are arrays (e.g.
{"mpi":["..."],"openmp":["..."]}) before passing it to conda build --variants;
keep using the same variable name variant_json and ensure the change preserves
the existing quoting/escaping around the --variants argument.

🧹 Nitpick comments (1)

.github/workflows/conda-release.yml (1)

51-58: Consider pinning auto-update-conda: false for reproducible release builds.

In a release workflow, auto-update-conda: true means the conda version can change between runs, potentially introducing inconsistencies. Pinning to false (and controlling the conda version explicitly) gives more reproducible release artifacts.