ci: implement workflow_run pattern for coverage comments

[g-husam]

• Moves PR commenting to a separate privileged workflow to support forks (see this failed workflow: https://github.com/google/ml-flashpoint/actions/runs/22157978839/job/64210308227?pr=43).
• Ensures coverage data is archived even on build failure.
• Uses explicit file existence checks for reliable comment posting.

[gemini-code-assist]

Summary of Changes

Hello @g-husam, 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 refines the continuous integration process by enhancing how code coverage comments are generated and posted, particularly for contributions from forks. It also improves the project's packaging metadata and adopts a dynamic versioning strategy, leading to a more robust and maintainable development workflow.

Highlights

• CI/CD Workflow Enhancement: The pull request commenting mechanism has been moved to a separate, privileged workflow. This change is crucial for enabling coverage comments to function correctly for pull requests originating from forks, addressing previous limitations.
• Robust Coverage Data Archiving: Modifications ensure that coverage data is consistently archived, even in scenarios where the build process might fail. This improves the reliability of coverage reporting.
• Reliable Comment Posting: Explicit file existence checks have been implemented to guarantee that coverage comments are posted only when the necessary data files are present, preventing erroneous or incomplete comments.
• Project Metadata and Dynamic Versioning: The project configuration (pyproject.toml) has been updated to include comprehensive project metadata such as readme, license, and classifiers. Additionally, dynamic versioning using setuptools-scm has been introduced for better version management.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• pyproject.toml
  • Updated project metadata to include readme, license, and a comprehensive list of classifiers.
  • Configured dynamic versioning by replacing a static version with dynamic = ["version"] and integrating setuptools-scm.
  • Added setuptools-scm as a build dependency.
  • Specified scikit_build_core.metadata.setuptools_scm as the version provider for scikit-build.

Ignored Files

• Ignored by pattern: .github/workflows/** (2)
  • .github/workflows/build-and-test.yml
  • .github/workflows/post-coverage-comment.yml

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. ↩

[gemini-code-assist]

Code Review

The pull request title and description describe CI workflow changes (implementing the workflow_run pattern, archiving coverage data, and adding file existence checks), but the provided code changes only modify pyproject.toml to implement dynamic versioning via setuptools-scm and add project metadata. This discrepancy should be resolved to maintain a clear project history. Technically, the transition to dynamic versioning is well-implemented, though adding a fallback version for setuptools-scm and including authors metadata would improve the package's robustness and completeness for distribution.

I am having trouble creating individual review comments. Click here to see my feedback.

pyproject.toml (22)

As you are adding project metadata for distribution, it is recommended to include the authors field in the [project] section as per PEP 621. This provides essential information for package consumers and registry displays.

dynamic = [ "version" ]
authors = [
    { name = "Google LLC" },
]

pyproject.toml (24)

The changes in this PR (implementing dynamic versioning and adding project metadata) do not align with the PR title and description, which focus on CI workflow improvements for coverage comments. Please update the PR metadata to reflect the actual changes or ensure that the intended CI configuration files are included in this PR.

pyproject.toml (133)

Consider adding a fallback_version for setuptools-scm. This prevents build failures when the project is installed from a source distribution that does not include the .git directory (e.g., a ZIP download from GitHub). This can be configured by adding a [tool.setuptools_scm] section with fallback_version = "0.0.0".