Skip to content
This repository was archived by the owner on Sep 9, 2026. It is now read-only.

Run golangci-lint automatically - #7

Merged
larsks merged 1 commit into
osac-project:mainfrom
larsks:fix/run-golangci-lint
Mar 26, 2025
Merged

larsks merged 1 commit into
osac-project:mainfrom
larsks:fix/run-golangci-lint

Conversation

@larsks

@larsks larsks commented Mar 26, 2025

Copy link
Copy Markdown
Member

This runs golangci-lint via pre-commit locally, and via the official github action 1 in our pre-commit workflow.

Summary by CodeRabbit

  • Chores
    • Enhanced our CI workflow with a new linting job for Go, ensuring more robust code quality checks.
    • Improved pre-commit configurations to enforce comprehensive validation, including checks for trailing whitespace, merge conflicts, and YAML correctness.
    • Streamlined formatter settings to clarify the structure for enabling and configuring checks for a more consistent development experience.

@coderabbitai

coderabbitai Bot commented Mar 26, 2025

Copy link
Copy Markdown

Walkthrough

The pull request introduces several modifications to enhance linting and pre-commit validation for Go projects. A new job named golangci-lint is added to the GitHub Actions workflow in .github/workflows/pre-commit.yaml, which sets up the Go environment and executes the golangci-lint tool. The existing pre-commit job is updated to include an extra_args parameter for a specific configuration file. In the .golangci.yml file, the management of linters is restructured, removing the disable-all directive and enabling the lll linter. A new configuration file, .pre-commit-config-ci.yaml, is introduced to define hooks from various repositories for code quality checks, including YAML linting. Additionally, the .pre-commit-config.yaml is updated to include a local repository hook for running golangci-lint on Go files.


🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

This runs golangci-lint via pre-commit locally, and via the official github
action [1] in our pre-commit workflow.

[1]: https://github.com/golangci/golangci-lint-action

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
.github/workflows/pre-commit.yaml (1)

18-30: New GolangCI-lint Job Configuration is Well-Structured
The newly introduced golangci-lint job correctly sets up the Go environment and invokes the linting tool using golangci/golangci-lint-action@v7 with version v2.0.

  • Note: It would be worthwhile to verify that version v2.0 is fully compatible with your project requirements and that any additional golangci-lint configurations (if needed) are provided either in a configuration file or inline.
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ade1bd2 and 834155f.

📒 Files selected for processing (4)
  • .github/workflows/pre-commit.yaml (1 hunks)
  • .golangci.yml (0 hunks)
  • .pre-commit-config-ci.yaml (1 hunks)
  • .pre-commit-config.yaml (1 hunks)
💤 Files with no reviewable changes (1)
  • .golangci.yml
🔇 Additional comments (4)
.pre-commit-config-ci.yaml (2)

1-13: Pre-commit Hooks (General) Configuration Looks Solid
The configuration from the pre-commit-hooks repository (v5.0.0) covers an extensive set of checks (trailing whitespace, merge conflicts, etc.) which is excellent for enforcing code quality.


14-21: YAML Lint Hook Configuration is Robust
The yamllint hook is well-configured with strict mode enabled and excludes the config/ directory as intended. This should help catch YAML syntax issues effectively.

.github/workflows/pre-commit.yaml (1)

15-16: Extra Arguments Update for Pre-commit Action
Adding the parameter extra_args: -c .pre-commit-config-ci.yaml directs the pre-commit action to use the CI-specific configuration file. This improves consistency between local and CI checks.

.pre-commit-config.yaml (1)

23-30: Local GolangCI-lint Hook Addition is Correctly Configured
The new local repository hook for golangci-lint is integrated properly:

  • It targets files with the .go extension.
  • Uses the system-installed version via language: system.
  • Disables passing filenames (using pass_filenames: false), which is appropriate if golangci-lint is configured to scan the repository as a whole rather than individual files.
    Make sure that this setting aligns with your intended workflow for locally invoking the linter.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
.github/workflows/pre-commit.yaml (1)

15-16: Extra Args Configuration for Pre-Commit Action
The added parameter extra_args: -c .pre-commit-config-ci.yaml ensures that the pre-commit hook uses a custom configuration for CI. Please verify that the file .pre-commit-config-ci.yaml exists in the repository root and is maintained in sync with local development settings.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 834155f and bc7ff91.

📒 Files selected for processing (4)
  • .github/workflows/pre-commit.yaml (1 hunks)
  • .golangci.yml (3 hunks)
  • .pre-commit-config-ci.yaml (1 hunks)
  • .pre-commit-config.yaml (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • .pre-commit-config.yaml
  • .pre-commit-config-ci.yaml
🔇 Additional comments (6)
.github/workflows/pre-commit.yaml (1)

18-29: New golangci-lint Job Integration
The new golangci-lint job is correctly defined. It checks out the repository, sets up the Go environment with the stable version, and subsequently runs the linting action using golangci/golangci-lint-action@v7 with version: v2.0. Please confirm that v2.0 is the desired version for your linting policies, as newer versions might offer additional features or fixes.

.golangci.yml (5)

5-8: Updated Linters Configuration
Replacing disable-all: true with default: none allows for a more granular enabling of selected linters. The enabled linters (e.g., dupl, errcheck, etc.) now reflect explicit choices, which enhances maintainability.


14-14: Activation of the 'lll' Linter
The addition of the lll linter in the enable list is a valuable enhancement to catch long line issues. Ensure that any custom thresholds (if needed) are configured elsewhere in the file or in your CI settings.


23-27: Revive Linter Settings Enhancement
The introduction of a dedicated settings block for the revive linter—with specific rules such as comment-spacings—improves the granularity of code style checking. Double-check that this rule conforms to your project's style guidelines.


27-40: Detailed Exclusions Configuration
The updated exclusions configuration now includes a generated: lax flag along with explicit rules and paths (e.g., exclusions for files matching api/*, internal/*, and directories like third_party, builtin, and examples). Review these patterns carefully to ensure no essential files are skipped during linting.


45-50: Formatters Exclusions Added
The formatter configuration now includes an exclusions block that applies generated: lax and omits formatting on specified paths, which helps avoid unintended changes to third-party or auto-generated code. This approach is clear and effective.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants