Adalennis opened a new issue, #9071:
URL: https://github.com/apache/hop/issues/9071
### Apache Hop version?
2.20.0-SNAPSHOT
### Java version?
Java 21
### Operating system
macOS
### What happened?
- The pre-commit hook doesn't lint what is being committed. It lints the
files on disk rather than the staged versions, so a password that is staged and
then removed only on disk is committed unchecked. It also selects files with
--diff-filter=ACM, so a pipeline renamed with git mv and given a password in
the same commit is never linted, while the same change without the rename is
blocked by SEC-002. Expected: lint the staged content (git show :<path>) and
include renamed files (ACMR).
- hop lint resolves relative paths against the Hop installation. Run from a
project folder, hop lint . lints the Hop installation, hop lint naming.hpl
reports "Target does not exist", and -o, -c, --baseline and --write-baseline
read or write inside the installation. Only hop lint with no target uses the
current folder, so the documented hop lint --output lint.sarif . lints the
wrong files. Expected: resolve relative paths against the folder the command
was run from (hop.origin.dir).
- --fail-on silently treats INFO and invalid values as ERROR. --fail-on INFO
and a typo such as --fail-on WARNNG both pass with exit 0 on a project with 11
warnings and 1 info, without a warning. The Run Linter action's Fail on offers
the same three values. Expected: support INFO, as -s does, and reject unknown
values.
- Invalid rule values are accepted and the rule silently never works. A
non-numeric value for a numeric condition ("abc", "${MAXT}", "3,0"), an invalid
pattern ("[a-") or a condition that doesn't fit the field (transformCount with
NOT_NULL) is accepted by Edit Lint Rule and when loaded from hop-lint.yml, and
the rule never reports anything. The incompatible condition fails silently; the
others log a NumberFormatException / PatternSyntaxException on every run.
Expected: Edit Lint Rule rejects such values on OK, saying why, and rules
loaded from hop-lint.yml or a pack get a warning naming the rule and the
problem, as for unknown rule ids.
- SYSTEM-001, SYSTEM-002 and SYSTEM-003 aren't listed or configurable.
Unreadable files and failed runs are reported as SYSTEM-001 (File Processing
Error), SYSTEM-002 (Configuration Error) and SYSTEM-003 (Unreadable Metadata),
always at ERROR. They are hardcoded rather than defined in hop-lint-core.yml,
so they don't appear in --list-rules, the Lint Rules Manager or the docs, and a
severity override is ignored with "which no installed rule pack defines".
Expected: define them in the core pack so they are listed, documented and
configurable.
- A broken rule pack's error doesn't name the pack. A broken
hop-lint-pack.yml stops hop lint with only "while parsing a flow sequence in
'reader', line 6, column 13", although the docs say the error names the file or
pack, as it does for a project's hop-lint.yml.
**Suggestions**
- Make suppressions easier to keep working. A suppression is stored by the
element's name (source), so renaming a transform or action drops it, and
suppress/exclude paths only match in their exact project-relative form
(naming.hpl, not ./naming.hpl, **/naming.hpl or an absolute path), with no
warning in either case. Updating source on rename, accepting the usual path
forms and warning about entries that match nothing would help.
- Lint Rules Manager: Toggle Enabled gives no feedback. The button always
reads "Toggle Enabled", and only the ✓/✗ in the far-right Enabled column
changes. It could read "Disable rule" / "Enable rule" for the selected rule, as
Delete Rule becomes "Restore pack rule", and disabled rules could be greyed out.
- Passwords with a literal part. NO_HARDCODED treats any value containing a
variable as not hardcoded, so a connection password of MyPassw0rd${PG_SUFFIX}
passes DB-001 although most of it is in the project. Mixing is fine for
hostnames or URLs; should any literal text count as hardcoded for password
fields?
- Run Linter: allow variables in Minimum severity, Fail on and Report
format, so thresholds can differ per environment. The combos accept typed text
such as ${FAIL_ON}, which is silently replaced by the default when the workflow
is reopened; if variables aren't supported, they could be read-only.
- Clearer error when rules: is written as a list. rules: with dashes, like
exclude and suppress, fails with "class java.util.ArrayList cannot be cast to
class java.util.Map". Saying that rules maps each rule id to its settings would
make the mistake obvious.
### Issue Priority
Priority: 3
### Issue Component
Component: Hop Gui
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
