5.16.0 silently drops custom PMD rulesets that point at a sibling file by relative path
まだ誰も着手していません。
評価
調査の方向性
Core PR #503で説明されているPMDプロセスのセットアップから始め、scanner/full.xml、scanner/subset.xml、code-analyzer.ymlを使って再現します。5.16.0でサンプル設定に対して sf code-analyzer rules --rule-selector pmd:MyRule を実行します。相対的なルール参照がリポジトリ設定から読み込まれ、MyRule がruleset-resolution errorなしで一覧表示されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
What you see
After upgrading to @salesforce/plugin-code-analyzer 5.16.0, a scan that used to run our custom PMD rules stops running them, and nothing fails. The exit code is still 0. The only sign is one Critical violation attached to no file, with a summary like Found 1 violation(s) across 0 file(s). A CI gate that does not use --severity-threshold reads green while zero Apex rules ran.
sf code-analyzer config and sf code-analyzer rules show the cause: Cannot resolve rule/ruleset reference 'scanner/<full-ruleset>.xml/<RuleName>'.
Why it happens
Our repo has two custom rulesets: a full one that defines the rules, and a smaller one that reuses some of them with <rule ref="scanner/full-ruleset.xml/RuleName"/>, a path relative to the repo root. Up to 5.15.x, PMD resolved that path against the repo being scanned, because the PMD process was started from there.
Core PR #503 (the CWE-427 hardening) now starts the PMD process from the engine's own install folder (cwd: __dirname). The PR calls this behaviour-preserving because every argument handed to java is an absolute path. That is true for the paths the engine passes, but not for paths written inside a custom ruleset: PMD still resolves those from the process's working directory, which is now the wrong folder. The whole ruleset then fails to load, and the PMD engine drops out of the run.
The 5.16.0 release notes do not mention it.
How to reproduce
scanner/full.xmldefinesMyRule.scanner/subset.xmlcontains<rule ref="scanner/full.xml/MyRule"/>.code-analyzer.ymlin the repo root lists both files underengines.pmd.custom_rulesets.- Run
sf code-analyzer rules --rule-selector pmd:MyRule. On 5.15.x the rule is listed. On 5.16.0 the ruleset fails to load with the error above.
Seen with plugin 5.16.0 (code-analyzer-core 0.53.0, pmd-engine 0.46.0, PMD 7.26.0) on macOS. The same configuration loaded cleanly on 5.14.0 and on the release before 5.16.0.
What would fix it
Any one of these:
- Resolve paths inside custom rulesets against the config file's folder or the workspace root. One way: keep the working directory pinned, but add the workspace root to PMD's classpath, so
scanner/...resolves as a classpath resource. - Or state in the
custom_rulesetsdocs and the 5.16.0 release notes that a custom ruleset must be self-contained (no relative<rule ref>to another file).
Workaround
Generate the smaller ruleset as a self-contained copy of the rules it needs, instead of pointing at the full one. That is what we now do.
- 主要言語
- Java
- スター
- 4
- フォーク
- 6
- 平均マージ
- 10時間 42分
- マージ済み PR(30日)
- 4
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
refinedmods/refinedstorage2#1414 · コメント 1 件 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
In Java's `LongBoundedSum`, setting `lower` to `Long.MIN_VALUE` under-estimates the sensitivityオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
google/differential-privacy#489 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
link-check link-check:manual
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100