ci: pre-commit --all-files newly red repo-wide from linter version drift (unpinned pylint/astroid under pylint-odoo)

[gonzalesedwin1123]

Symptom

CI's pre-commit job (pre-commit run --all-files --show-diff-on-failure, .github/workflows/pre-commit.yml) is failing on pre-existing code across the whole repo, independent of any single PR.

Proof it is drift, not a code change: commit 0dc69f08 (current 19.0 HEAD) had a successful CI run on 2026-07-14 (pre-commit is a required check, so it passed then). The identical commit fails pre-commit today (2026-07-24). No code changed in between — only freshly-installed linter/plugin versions.

Scope of the new failures (all pre-existing code)

• pylint_odoo — ~200 translation-required (C8107) across ~22 modules, e.g. spp_key_management (71), spp_api_v2 (49), spp_api_v2_change_request (13), spp_api_v2_gis (12), spp_studio (12), spp_dci_client (10), spp_dci_client_sr (9), spp_dci_server (8), plus spp_programs, spp_change_request_v2, spp_vocabulary, spp_cel_widget, spp_area, and others.
• eslint — errors in JS under ~6 modules: spp_branding_kit, spp_cel_widget, spp_change_request_v2, spp_drims, spp_studio/static/src/js/logic_editor.

Likely cause

.pre-commit-config.yaml pins the hook repo revs (OCA/pylint-odoo rev: v9.3.15; eslint@9.35.0 / eslint-plugin-jsdoc@57.0.8) but the pylint_odoo hooks do not pin their transitive Python deps (pylint, astroid) via additional_dependencies. pre-commit installs those fresh in an isolated venv on each CI run, so a pylint/astroid release after 2026-07-14 changes analysis behaviour and newly fires C8107 on long-standing code. (The eslint side is likely the same class — a floated transitive/plugin resolution; worth confirming.)

Impact

• Blocks the pre-commit check on every new or re-run PR, including the in-flight security-campaign PRs. PRs that currently show pre-commit = pass are stale runs from before the drift; re-running them will hit the same wall.
• Code correctness is unaffected — module test suites and the other CI jobs pass.

Recommended fix (pick one)

1. Pin the transitive deps in the pylint_odoo hook additional_dependencies (e.g. the pylint/astroid versions that were installed for the passing 2026-07-14 run) so linter behaviour is reproducible; do the equivalent for eslint if it also floated. Restores green without touching module code.
2. Clear the debt: add the missing self.env._(...) translation wrappers across the flagged modules and fix the eslint findings. Larger, but removes the debt permanently. Should be its own scoped PR(s), not mixed into feature/security PRs.

Option 1 is the fast unblock; option 2 can follow. Either way, this should not be fixed inside unrelated feature PRs (scope/reviewability).

Repro

git checkout 0dc69f08
pre-commit run pylint_odoo --all-files   # newly fails on C8107 across ~22 modules
pre-commit run eslint --all-files        # newly fails across ~6 JS modules

Found while landing the demo-default-credentials PR (#356), whose own four modules are lint-clean (zero hits) but whose pre-commit check is red solely due to this drift.

[gonzalesedwin1123]

Correction / update. The failure is flaky (non-deterministic), not a persistent repo-wide block — I overstated it in the original report.

On a re-run of the same branch (only a README-regen commit added, touching no Python/JS), the pre-commit job went fully green: eslint … Passed, pylint with optional checks … Passed. So the earlier translation-required/eslint failures on unchanged code were a spurious red from one install of the unpinned transitive linter deps, which cleared on the next install ~1.5h later.

Revised characterization:

• Not "every PR is blocked" — pre-commit currently passes. Existing green PRs are fine.
• The real, still-valid issue is non-deterministic CI: because the pylint_odoo hook's pylint/astroid (and likely an eslint transitive) aren't pinned in additional_dependencies, a floating plugin release can make a run spuriously fail on pre-existing code, then pass on retry. That's a flaky-CI risk, not a hard outage.

Recommendation is unchanged but lower urgency: pin the transitive linter deps for reproducible runs. No need to touch the 22 modules' code. Apologies for the initial over-escalation — the observed behavior is intermittent, not a standing red.