chore: add YAML linting to CI

[CybotTM]

Add yamllint to the lint CI workflow to validate YAML files.

[gemini-code-assist]

Summary of Changes

Hello @CybotTM, 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 automated YAML linting into the continuous integration pipeline. The primary goal is to enhance code quality and consistency across all YAML configuration files by catching potential issues early in the development cycle, thereby improving maintainability and reducing errors.

Highlights

• YAML Linting: Integrated yamllint into the CI workflow to automatically validate YAML files, ensuring consistency and catching potential issues early.
• Configuration: Added a .yamllint.yml configuration file to define specific linting rules, disabling checks for line length, truthy values, document start, and comments indentation to suit project needs.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/lint.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 configuration file for yamllint. While adding a linter is a positive step towards improving code quality, the current configuration disables several important linting rules. My feedback focuses on revising this configuration to be less permissive, ensuring that the linter can effectively catch potential issues and enforce readability, particularly by re-enabling checks for ambiguous boolean values and comment indentation, and setting a reasonable line length limit instead of disabling the check entirely.

[gemini-code-assist]

Disabling several useful linting rules can reduce the effectiveness of yamllint.

• line-length: Instead of disabling this rule completely, consider setting a generous limit to maintain readability, for example max: 120. This prevents excessively long lines which are hard to read.
• truthy: This is a crucial rule that prevents ambiguous boolean values (e.g., on, off). Disabling it can introduce subtle bugs where a string is unintentionally parsed as a boolean. It's highly recommended to keep it enabled and quote string values that look like booleans (e.g., "on").
• comments-indentation: This rule helps maintain consistent formatting and readability. It's better to keep it enabled to ensure comments are properly aligned.

I'd suggest only disabling rules for which there is a strong reason, like document-start if you prefer not to have --- in your files. The other rules provide significant value in maintaining YAML file quality.

  line-length: {max: 120}
  document-start: disable