Our open and extensible platform lets you customize your analysis to surface the issues your team cares about most.
When you first add a repo to Code Climate we’ll auto-generate a
.codeclimate.yml file, based on the languages we detect in your repo. You can then download and make changes to this file to fine tune which engines and checks are running on your project. We also honor the configuration files of the underlying native static analysis tools, such as .rubocop.yml, and .eslintrc.
Code Climate Analysis Configuration
To access the
.codeclimate.yml containing the inferred configuration for your repo, head to your repo's individual page, and append
analysis_config to the URL. Example: https://codeclimate.com/repos/592dd25fc6ce3f0266000383/analysis_config
For repos added after July 2017, the .codeclimate.yml may not be available at the above-mentioned URL. If you experience a 404, please generate the .codeclimate.yml locally by using the Code Climate CLI.
As can be seen in this sample file, the 3 major nodes for customization are:
To add an engine to your analysis, simply add the following to your .codeclimate.yml configuration file and commit to the root of your repository:
engines: [engine name]: enabled: true
You can find the complete list of available engines here.
You can disable which engines are running on your project in both your .codeclimate.yml and from your Issues page.
Using your .codeclimate.yml
If you know the name of the engine you'd like to disable, you can simply mark the engine as enabled: false in the .yml, as shown here:
engines: rubocop: enabled: true eslint: enabled: false csslint: enabled: true
Using your Issues page
Or, if you’re not sure which engine is reporting the issue you’d like to silence, just click on the issue from your Issues page and choose the relevant link for instructions to disable the entire engine or just the specific check:
For configuration of specific engines, please see the documentation for that engine.
Your auto-generated .codeclimate.yml comes with a list of excludes that we think make sense for your project, including third party libraries, production assets (such as minimized or cross-compiled files), and automated test suites.
You can customize these or specify additional files or directories that you'd like to exclude using the exclude_paths key.
To learn how to exclude
- specific files and file types at any level
- tests and specs or a vendor directory at any level
- paths for specific engines, or
- single files
Please refer to our guide to Excluding Files and Folders.
You can configure your analysis to assign a letter grade for each class, module or file based on its maintainability – where ‘A’ is very easy to maintain, and ‘F’ is, well, not. Code Climate will then score your repository overall by aggregating the grades for each class/module/file, weighted by lines of code, into an overall average. Your score is provided as a **GPA which ranges from 0.0 to 4.0.
ratings: node in your
.codeclimate.yml specifies which files and folders receive a letter grade or contribute to the overall Code Climate score for your project. For example:
ratings paths "app/**/*" "lib/**/*" "**.rb" "**.go"
Issues in files not listed in either the ratings or exclude_paths nodes won’t count toward your repo's overall score, but will still be reported on your Issues page or browser extension.
Grades and scores are great for quickly identifying which areas of your codebase are improving or declining. That said, this isn’t school, and receiving individual grades or an overall project is entirely up to you – just don’t specify any files or folders under your ratings paths and your project won't receive individual grades or an overall score.
Next, we’ll look at how to add your custom analysis to your development workflow, so your team gets static analysis results on every change, and has the information they need to improve code quality with every commit.