"Include linters and code formatters for the programming and configurations that you are using in your repositories. That is, you likely include at least three static analysis tools as software quality gates into your CI/CD pipelines. One linter and one code formatter for your main programming language, one linter for your Dockerfiles. Add other suitable linters, e.g., in case you rely on shell scripts shellcheck, etc. You might want to start searching for relevant tools for your respective languages and frameworks here: https://github.com/mre/awesome-static-analysis.
Include all of these tools in a way that you either abort build in case quality of your code is too low (you will have to define some threshold here) or that you decide to trust them and let the tools try to automatically fix problems (in case you find a tool that supports that). In the latter case, you want to let the corresponding tool contribute the applied changes back to the corresponding source repository."
"Include linters and code formatters for the programming and configurations that you are using in your repositories. That is, you likely include at least three static analysis tools as software quality gates into your CI/CD pipelines. One linter and one code formatter for your main programming language, one linter for your Dockerfiles. Add other suitable linters, e.g., in case you rely on shell scripts shellcheck, etc. You might want to start searching for relevant tools for your respective languages and frameworks here: https://github.com/mre/awesome-static-analysis.
Include all of these tools in a way that you either abort build in case quality of your code is too low (you will have to define some threshold here) or that you decide to trust them and let the tools try to automatically fix problems (in case you find a tool that supports that). In the latter case, you want to let the corresponding tool contribute the applied changes back to the corresponding source repository."