Configuring Your Analysis

Our open and extensible platform lets you customize your analysis to surface the issues your team cares about most.

For repos added before July 2017, please see our section on Advanced Configuration.

Maintainability Checks

When you first add a repo to Code Climate, we’ll analyze your code using our 9-point maintainability assessment.

These individual checks can be enabled/disabled on the Maintainability tab of your repository's Settings page.

Engines

In addition to the 9-point maintainability analysis, you can choose to implement over 30+ style, linting, and security static analysis tools. These Engines can be individually enabled on the Plugins tab of your repository's Settings page.

Exclude patterns

You can choose to exclude certain files and directories from our analysis. This can be done using the Exclude patterns tab on your repository's Settings page. By default, we exclude a list of common folders paths for tests, configuration files, and vendor code. To learn more about recommended exclusions, visit our docs here.

Advanced Configuration: Using `.codeclimate.yml`

For repos added before July 2017, a committed .codeclimate.yml is required for any advanced configuration.

In addition to the configurations available in your repository's Settings page, you can choose to commit a .codeclimate.yml configuration file. This is helpful for those who prefer more finely-tuned configuration of third-party engines, or wish to keep their configuration in version control. A .codeclimate.yml is helpful for some of the following use cases:

To generate a default .codeclimate.yml for your repo, use the Code Climate CLI.

Configurations done within a committed codeclimate.yml will override any conflicting configurations made on your repository's Settings page.

As can be seen in the sample file below, the 3 major nodes for customization are:

engines:
  rubocop:
    enabled: true
    #checks:
    #	Rubocop/Metrics/ClassLength:
    #  	enabled: false
  golint:
   	enabled: true
  eslint:
    enabled: true
  csslint:
    enabled: true
  duplication:
  	enabled: true
    config:
    	languages:
      - ruby
      	#mass_threshold: 30
      - javascript
ratings:
  paths:
  - app/**
  - lib/**
  - "**.rb"
  - "**.go"
exclude_paths:
- spec/**/*
- "**/vendor/**/*"

Engines

Adding engines to your analysis

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.

Removing engines from your analysis

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:

Configuring individual engines

For configuration of specific engines, please see the documentation for that engine.

Exclude Paths

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.

Ratings

Beginning in July 2017, repos added by new organizations will no longer receive a GPA. The GPA will be replaced by a maintainability rating based on our 9-point maintainability assessment.

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.

The 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.

Configuring Your Analysis