Skip to content

@W-21974851: feat- Add workingDirectory parameter and fix selector rule name support#439

Open
aruntyagiTutu wants to merge 5 commits intomainfrom
fix/selector-rule-name-support
Open

@W-21974851: feat- Add workingDirectory parameter and fix selector rule name support#439
aruntyagiTutu wants to merge 5 commits intomainfrom
fix/selector-rule-name-support

Conversation

@aruntyagiTutu
Copy link
Copy Markdown
Contributor

@aruntyagiTutu aruntyagiTutu commented Apr 10, 2026

Summary

@W-21974851@ - Adds workingDirectory parameter for automatic config discovery and fixes selector validation to support rule names.

Changes

1. workingDirectory Parameter

  • Added mandatory workingDirectory parameter to run_code_analyzer tool
  • Automatically searches for code-analyzer.yml/yaml in the specified directory
  • configPath remains optional for custom config file names/locations
  • Priority: configPath → workingDirectory config discovery → defaults

2. Selector Rule Name Support

  • Removed strict token validation that rejected rule names
  • Now supports: "WhileLoopsMustUseBraces", "WhileLoopsMustUseBraces:pmd", etc.
  • Delegates validation to code-analyzer-core (validates syntax, accepts any tokens)

Usage

// Standard case - auto-discovers config
{
  target: ["/workspace/MyFile.cls"],
  workingDirectory: "/workspace"
}

// Rule name selector
{
  target: ["/workspace/MyFile.cls"],
  workingDirectory: "/workspace",
  selector: "WhileLoopsMustUseBraces:pmd"

Allow users to specify an optional absolute path to a Code Analyzer
configuration file. This enables using config files from locations
other than the current working directory.

Changes:
- Added configPath optional parameter to run_code_analyzer input schema
- Updated CodeAnalyzerConfigFactory to accept and validate configPath
- Added validation for absolute path and file existence
- Updated RunInput type and RunAnalyzerActionImpl to pass configPath
- Added comprehensive unit tests for the new functionality

The tool now searches for config in this order:
1. If configPath is provided, use that file (with validation)
2. Otherwise, search for code-analyzer.{yml,yaml} in cwd
3. If no config found, use default configuration

Fixes issue where config files were only loaded from process.cwd()
and not from the workspace where target files are located.
Changed behavior: When configPath is not provided, the tool now uses
default configuration instead of searching for config files in the
current working directory.

Rationale: The previous automatic discovery used process.cwd() which
is the directory where the MCP server runs, not where target files
are located. This caused confusion as config files in the workspace
were being ignored.

Changes:
- Removed seekConfigInCurrentDirectory() method and related constants
- Updated description to clarify that omitting configPath uses defaults
- Updated describe-rule tests to explicitly provide config instead of
  relying on automatic discovery via process.chdir()

With this change, config is only loaded when explicitly specified via
the configPath parameter, making the behavior predictable and explicit.
Updated tool description and parameter description to explicitly
instruct the LLM to:
1. Search for code-analyzer.yml/yaml in workspace root before running
2. Pass the absolute path via configPath parameter if found
3. Understand that config files contain custom rules and must be respected

This guidance ensures LLMs will automatically discover and use
configuration files in the user's workspace, making the tool behavior
more intuitive and less error-prone.
…iscovery

Added workingDirectory as a required parameter that enables automatic
discovery of code-analyzer.yml/yaml files. This provides a simpler
alternative to explicitly passing configPath.

Changes:
- Added mandatory workingDirectory parameter to run_code_analyzer input
- Factory now searches for code-analyzer.{yml,yaml} in workingDirectory
- configPath remains optional for custom config file names/locations
- Priority: configPath > workingDirectory config discovery > defaults
- Added comprehensive validation and tests for both parameters
- Updated all test files to include workingDirectory

Usage:
- Standard case: Pass workingDirectory, auto-discovers config files
- Special case: Pass configPath for custom config names/locations
- Both: configPath takes precedence over workingDirectory discovery

This makes it easy for LLMs to just pass the workspace directory
without having to search for and construct config file paths.
The run_code_analyzer tool was rejecting selectors containing rule names
(e.g., "WhileLoopsMustUseBraces") because it validated against a strict
list of allowed tokens (engines, tags, severities only).

However, code-analyzer-core's selectRules() accepts ANY selector string
including direct rule names. The core validates syntax (colons, commas,
parentheses) but accepts any token value.

Changes:
- Removed validateSelectorIfProvided() function and its call
- Removed unused import of CodeAnalyzerListRulesMcpTool
- Removed test for "invalid selector tokens" (no longer applies)
- Added test to verify rule names work in selectors
- Updated description to document rule name support with examples
- Updated selector parameter description

Now supports:
- Rule names: "WhileLoopsMustUseBraces", "no-unused-vars"
- Engines: "pmd", "eslint"
- Tags: "Security", "Performance"
- Severities: "Critical", "1", "2"
- Combinations: "WhileLoopsMustUseBraces:pmd", "Security:eslint"

The tool still validates against unsupported engines (sfge, flow) but
delegates all other selector validation to code-analyzer-core.
@aruntyagiTutu aruntyagiTutu requested a review from a team as a code owner April 10, 2026 04:44
@aruntyagiTutu aruntyagiTutu changed the title @W-21974851 - feat: Add workingDirectory parameter and fix selector rule name support @W-21974851: feat- Add workingDirectory parameter and fix selector rule name support Apr 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant