android/app/lint-baseline.xml now holds only the entries lint still applies, and android/app/build.gradle.kts records that count in a comment. Nothing keeps either true.
Running ./gradlew updateLintBaseline, which is the documented way to edit the file, rewrites it from 17 entries to roughly 92. That restores every machine-specific location and additionally buries issue types that were never baselined, including ones currently reported.
Nothing can notice:
LintBaselineFixed, the issue lint raises for a baseline entry that matches nothing, is Information severity and can never fail a build.
git grep "lint-baseline\|lintBaseline" reaches only the comment and the baseline = assignment, so no check-*.py reads the file.
The count is printed mechanically in every lint report (N warnings were filtered out because they are listed in the baseline file), so a check comparing that number against the entry count in the XML is cheap. Failing the build when a baseline grows without an accompanying change would catch both the accidental regeneration and the slower drift that produced the 42 stale entries in the first place.
Related: #227.
android/app/lint-baseline.xmlnow holds only the entries lint still applies, andandroid/app/build.gradle.ktsrecords that count in a comment. Nothing keeps either true.Running
./gradlew updateLintBaseline, which is the documented way to edit the file, rewrites it from 17 entries to roughly 92. That restores every machine-specific location and additionally buries issue types that were never baselined, including ones currently reported.Nothing can notice:
LintBaselineFixed, the issue lint raises for a baseline entry that matches nothing, is Information severity and can never fail a build.git grep "lint-baseline\|lintBaseline"reaches only the comment and thebaseline =assignment, so nocheck-*.pyreads the file.The count is printed mechanically in every lint report (
N warnings were filtered out because they are listed in the baseline file), so a check comparing that number against the entry count in the XML is cheap. Failing the build when a baseline grows without an accompanying change would catch both the accidental regeneration and the slower drift that produced the 42 stale entries in the first place.Related: #227.