Skip to content

Conversation

@ziggie1984
Copy link
Collaborator

This make command does not run in the CI but can make it easier
to resolve all linter issues when developing on a separate module
which only in followup PRs will be used in the main line.

Usage for example:

make lint-module module=kvdb

@ziggie1984 ziggie1984 self-assigned this Dec 18, 2025
@gemini-code-assist
Copy link

Summary of Changes

Hello @ziggie1984, I'm Gemini Code Assist1! 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 make command and an accompanying script to enable more granular and efficient static code analysis for Go submodules. The primary goal is to empower developers to proactively identify and resolve linter issues within individual modules during their development cycle, thereby improving code quality and reducing friction when integrating these modules into the main codebase. This enhancement streamlines the development workflow for projects utilizing a modular structure.

Highlights

  • New make lint-module command: A new make command, lint-module, has been introduced to allow developers to run static code analysis specifically on Go submodules. This command is designed for local development and does not run in CI.
  • Targeted or comprehensive submodule linting: The lint-module command can be used to lint all detected submodules or a specific submodule by passing the module=<name> argument (e.g., make lint-module module=kvdb).
  • Dedicated linting script: A new shell script, scripts/lint_modules.sh, has been added to encapsulate the logic for finding and linting submodules. This script handles the execution of golangci-lint within a Docker container.
  • Intelligent Docker caching: The linting script incorporates a robust Docker caching strategy, differentiating between CI environments (using bind mounts to host paths) and local development (using Docker named volumes for improved performance on macOS/Windows).
  • Flexible linter configuration: The script intelligently checks for a .golangci.yml configuration file within each submodule's directory. If a submodule-specific configuration is not found, it defaults to using the root .golangci.yml.

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

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.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

The pull request introduces a new "make lint-module" command and a corresponding "scripts/lint_modules.sh" script. This is a valuable addition for developers working on individual submodules, as it streamlines the linting process outside of the main CI pipeline. The script correctly handles both specific module linting and iterating through all submodules, and intelligently uses Docker caching for performance.

# Accept optional module parameter
TARGET_MODULE=$1

IGNORE="tools"

Choose a reason for hiding this comment

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

medium

The "IGNORE" variable is hardcoded to "tools". This reduces the flexibility of the script, as any changes to the list of ignored modules would require direct modification of this file. Consider making this configurable via an environment variable to improve maintainability.

Suggested change
IGNORE="tools"
IGNORE="${LINT_IGNORE_MODULES:-tools}"

SUBMODULES="$TARGET_MODULE"
else
# Otherwise, lint all submodules
SUBMODULES=$(find . -mindepth 2 -name "go.mod" | cut -d'/' -f2 | grep -v "$IGNORE")

Choose a reason for hiding this comment

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

medium

This line exceeds the 80-character limit specified in the Repository Style Guide (Line 11). Please wrap the command to adhere to this limit for better readability and consistency.

Suggested change
SUBMODULES=$(find . -mindepth 2 -name "go.mod" | cut -d'/' -f2 | grep -v "$IGNORE")
SUBMODULES=$(find . -mindepth 2 -name "go.mod" | \
cut -d'/' -f2 | grep -v "$IGNORE")
References
  1. The line length MUST NOT exceed 80 characters. Tabs are 8 spaces. (link)

This make command does not run in the CI but can make it easier
to resolve all linter issues when developing on a separate module
which only in followup PRs will be used in the main line.

Usage for example:

make lint-module module=kvdb
@lightninglabs-deploy
Copy link

@Roasbeef: review reminder
@ziggie1984, remember to re-request review from reviewers when ready

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants