Tank you for the reply. How do you configure those tools to only flag something as a bad build when the new code doesn't conform to those qualities? Is it something specific to you build workflow?
Some will let you specify files or directories to exclude. Others let you enable/disable one rule at a time.
It took us about 18 months of gradual chipping away to get our codebase to pass a linter, enabling one rule or class of rules at a time.
We're still working on test coverage. The key is to make sure all new code is covered (enforce in code review) and then very gradually backfill the rest. Add reproduction before fixing a bug. Add end to end coverage before a refactoring.
That depends on the tooling used. One way for linters and static analysers is to only run them on files touched by commits. For test coverage (if that is important) you can use something similar to detect the coverage for those relevant files. It really depends on your setup though.
It took us about 18 months of gradual chipping away to get our codebase to pass a linter, enabling one rule or class of rules at a time.
We're still working on test coverage. The key is to make sure all new code is covered (enforce in code review) and then very gradually backfill the rest. Add reproduction before fixing a bug. Add end to end coverage before a refactoring.