Fix two lint configuration traps - #3121
Draft
StylianosGakis wants to merge 2 commits into
Draft
Conversation
This was referenced Sep 3, 2026
StylianosGakis
force-pushed
the
chore/lint-config-fixes
branch
from
September 3, 2026 08:31
dd3a0e8 to
350e422
Compare
StylianosGakis
changed the base branch from
develop
to
chore/fix-ktlint-formatting
September 3, 2026 08:32
StylianosGakis
force-pushed
the
chore/lint-config-fixes
branch
from
September 4, 2026 13:20
350e422 to
dab15bf
Compare
Lint aborts the build whenever it has to create a baseline, and it does so even when it found nothing to put in one. Every module the lint convention plugin touches was therefore required to carry a checked-in baseline, so adding any new module failed `./gradlew lint` with a message that names neither the module nor the reason. Worse, the baseline lint leaves behind on that first run records whatever it found, so a re-run passes and any real error in the new module is suppressed from then on. Pointing `baseline` at the file only when it exists removes both problems. Modules that suppress findings today keep their baseline and behave exactly as before, and a module without one simply reports its findings.
Renovate owns dependency freshness in this repo, so lint's GradleDependency and NewerVersionAvailable notices are duplicate signal that nobody acts on. They resolve against the shared root gradle/libs.versions.toml rather than the module being linted, so they report identically regardless of which module runs lint, and :hedvig-ktlint surfaced 77 of them for dependencies it does not declare.
StylianosGakis
force-pushed
the
chore/lint-config-fixes
branch
from
September 4, 2026 16:52
dab15bf to
722e709
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 AI description:
Two lint configuration fixes. Both surfaced while adding a new module, neither is specific to it. #3132 above is the follow-through: it deletes the 104 baselines this requirement produced.
Only set the baseline when the module has one. The convention plugin pointed
baselineatlint-baseline-<module>.xmlunconditionally, and lint aborts the build whenever it has to create that file, even when it found nothing to put in it. Adding any new module therefore failed./gradlew lintwith a message naming neither the module nor the cause.In practice this has been harmless, which is why 104 of the 105 checked-in baselines are empty: modules here produce no findings, so the generated file was empty and committing it suppressed nothing. The cost is the ritual and the failure itself, which nobody adding a module should have to learn.
It is not harmless when a module does have findings. The baseline lint writes records whatever it found, and the abort message tells you to re-run, so the second run passes. Demonstrated with 18 error-severity findings: run one aborts after writing all 18 into the baseline, and run two reports
no new issues (and 18 errors filtered by baseline)with the build succeeding, nothing fixed.Setting
baselineonly when the file exists removes both. Modules that carry a baseline behave exactly as before, and none are deleted in this PR.Ignore version catalog staleness.
GradleDependencyandNewerVersionAvailableresolve against the shared rootgradle/libs.versions.tomlrather than the module being linted, so they report identically wherever lint runs and only a root-level module ever surfaces them.renovate.jsonalready owns dependency freshness, so they are duplicate signal nobody acts on, and 77 of them appeared against a module that declares none of those dependencies. Both are now ignored in the sharedlint.xml../gradlew lintpasses across the repo.