Update CI

[XucSh]

Description

Type of Change

• Types
  • Bug fix
  • New feature
    • Transfer Engine
    • Mooncake Store
    • Mooncake EP
    • Integration
    • P2P Store
    • Python Wheel
  • Breaking change
  • CI/CD
  • Documentation update
  • Other

How Has This Been Tested?

Checklist

• I have performed a self-review of my own code.
• I have updated the documentation.
• I have added tests to prove my changes are effective.

[gemini-code-assist]

Summary of Changes

Hello @XucSh, 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 introduces a new CI/CD configuration file to automate the labeling of pull requests. By adding a .github/labeler.yml file, the system will now automatically apply a run-ci label to any pull request that includes changes to any file. This change aims to streamline the CI process by ensuring that all pull requests are appropriately tagged for continuous integration workflows.

Highlights

• New CI/CD Configuration: A new GitHub Actions labeler configuration file, .github/labeler.yml, has been introduced to automate labeling workflows.
• Automated Labeling: The new configuration defines a run-ci label that will be automatically applied to any pull request that modifies any file within the repository.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/ci.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

This pull request introduces a GitHub Actions labeler configuration to automatically apply the run-ci label. However, the current configuration is overly broad, as it applies the label for changes to any file in the repository. This could lead to unnecessary CI runs for non-code changes, such as updates to documentation. My review includes a suggestion to make the file matching patterns more specific to improve efficiency.

[gemini-code-assist]

The current glob pattern '**/*' is very broad and will match any file change in the repository, including documentation, .gitignore files, or other non-code assets. This will cause the run-ci label to be applied to every pull request, potentially triggering unnecessary CI workflows and consuming resources. It's better to restrict this to files that actually require CI validation, such as source code and test files. Please adapt the suggested patterns to your project's specific structure.

    - any-glob-to-any-file:
      - 'src/**/*'
      - 'tests/**/*'
      # Add other relevant files/directories that should trigger CI

[XucSh]

Have tested： XucSh#3