Search results for "{{ search.query }}"

No results found for "{{search.query}}". 
View All Results

Switching to Engines-based Analysis

In June 2015 we launched the Code Climate Platform. You can learn all about it on our blog!

When using the Code Climate Engines, your results come from the individual analysis engines you’ve enabled. New repositories added to Code Climate use our platform by default. If your repository is running our Classic analysis, and you'd like to switch to our engines-based analysis, you can enable it at anytime from your repository's settings.

This doc covers:

Enabling the Code Climate engines
Analysis Comparison

Enable Code Climate Engines

A few grade-related things to keep in mind when enabling our engines analysis:

  • Engines Only: Each file will be graded solely based on the issues found via the engines you've enabled. As mentioned above, we do not run engines along side of the traditional analysis we do for Ruby, PHP, Python and JavaScript. They are a full replacement. As a result, your grades may change for individual files and your overall GPA.

  • Config file: On our platform, you'll specify which files you want graded using your .codeclimate.yml file, via a ratings: node. If you don't specify any files, your project won't have a GPA.

  • Ruby Files versus Classes/Modules: On our platform, we grade individual files, for all languages. This is different than our traditional Ruby analysis, where we graded classes/modules, not files.

  1. From your repo, mouse over the repository's name and click Settings.
  1. Select the Code Climate engines tab.
  1. Click the Use engines to analyze my repo button.

Test-driving Engines-Based Analysis

If you would like to have the option to stay on classic while test-driving the new engines-based analysis, it is possible, with some extra steps, to run both Classic and engines-based analysis simultaneously.

Analysis Comparison

When using the Code Climate Engines, the analysis results come from the individual engines that you enable in your .codeclimate.yml file. This means that we'll run different checks than in our classic analysis for Ruby, JavaScript, PHP, and Python projects.

Below are detailed breakdowns comparing our engines-based analysis to our classic analysis.

Our new platform supports more languages/engines than our Classic analysis. See our complete list!

Classic-Inspired Analysis Configuration for Engines

If you're looking for a simple analysis configuration for engines similar to our Classic offering, please see our documentation on classic Analysis Configuration.

Ruby Analysis

Type

Description

Complexity:

Our classic Ruby complexity analysis was provided via a fork of Flog.

We have implemented similar checks in our new platform's RuboCop engine, including cyclomatic complexity, length, and ABCSize. These are configurable in your .rubocop.yml file. Check out the RuboCop docs for our recommended defaults.

Duplication:

Our classic Ruby duplication analysis was provided by a fork of Flay, a tool that identifies repeated similar and identical code structures.

On our new platform, we have implemented a Duplication engine to provide the same functionality.

Style:

Our platform runs a RuboCop engine, which enforces many of the guidelines outlined in the community Ruby Style Guide. Users can choose from a variety of style check options configurable in their .rubocop.yml config file. Note that by default Ruby style checks are disabled for analyses running with an inferred configuration, so that your team can make its own style choices.

Security:

Our platform runs a Bundler Audit engine, which provides patch-level verification checks for Bundler.

In addition, our classic Ruby security analysis was provided by a fork of Brakeman (but analogous to version 2.6.2). We have implemented a Brakeman OSS engine on our platform to identify vulnerabilities in Rails projects, which runs much closer to the latest version of Brakeman.

Other:

Our platform runs a Rubymotion Engine, which analyzes RubyMotion projects.

Additionally, our engines typically run with newer versions of Ruby parser. If you're seeing missing files running classic, upgrading to our platform analysis may resolve those issues.

JavaScript Analysis

Type

Description

Complexity:

Our classic JavaScript complexity analysis was based on the ABC metric.

Our platform currently offers an ESLint engine, which checks for cyclomatic complexity.

Duplication:

Our original JavaScript duplication analysis was provided by a fork of Flay, a tool that identifies repeated similar and identical code structures.

On our new platform, we have implemented a Duplication engine to provide the same functionality.

Style:

Our original JavaScript style checking was provided by JSHint.

On our platform, we have implemented an ESLint engine, which provides similar style checks in a greater variety. The specific checks and threshold settings may be configured in a .eslintrc.js config file.

Python Analysis

Type

Description

Complexity:

Our platform runs a Radon engine, which provides analysis of cyclomatic complexity.

Style:

On our platform, we now offer a pep8 engine, which provides feedback on Python code style following the rules outlined in the PEP 8 style guide.

Duplication:

On our new platform, we have implemented a Duplication engine.

PHP Analysis

Type

Description

Complexity:

Our platform runs a PHP Mess Detector engine, which provides analysis of cyclomatic complexity.

Clarity / Bug Risk:

Our PHP Mess Detector engine also detects code smells and possible errors.

Style:

Our PHP Code Sniffer engine detects violations of a defining coding standard. By default, we use the PSR-1 basic coding standard and PSR-2 style guide.

Duplication:

On our new platform, we have implemented a Duplication engine that analyzes php code.

Running Classic and Engines-Based Analysis Simultaneously

If your team plans on making a switch to engines-based analysis from Classic, but would like a chance to configure your new analysis before switching, with a few extra steps you can run both forms of analysis simultaneously:

1. Manually add your repository via its URI to Code Climate a second time.
Your organization will have the same GitHub repository twice on your Code Climate dashboard when you have completed this step. This is expected. For clarity, you may want to rename your repositories on Code Climate (e.g. My Repo - Classic). This can be done under your repository settings.

Why add manually via URI?

Clicking "Add Repo" with our more streamlined import process automatically enables GitHub pull request integration.

While it is possible to add the same GitHub repository to Code Climate more than once, Code Climate only supports GitHub status integration with one Code Climate repository. If two Code Climate repositories are integrated with GitHub at the same time, they will both attempt to post a status update and overwrite one another.

Manually adding a repository to Code Climate prevents this scenario. If you already added a repo via "Add Repo", you can disable the GitHub integration for one of your repositories under Settings / Integrations / GitHub Pull Requests for that repository.

2. Commit a .codeclimate.yml (and any other configuration files) to your repository
If you have content in your .codeclimate.yml file (a languages key), retain the old content, and add the new engines-based configuration in addition. For a first pass, we recommend using Code Climate's Default Analysis Configuration.

3. View and customize your engines-based analysis results
By browsing the Issues tab for your new Code Climate repository, you can start to get a sense for your analysis configuration. Additionally, you'll want to audit the kinds of issues that will start to fail your pull requests. This can be done by entering the URL for the analysis results for pull requests manually. The URL will be: https://codeclimate.com/repos/REPO_ID/pull/PR_NUMBER. For example: https://codeclimate.com/repos/6660443afb4faa6c26003c0c/pull/10

4. When ready, switch over your Pull Request Integration to your new engines-based analysis results.
Start by disabling pull request integration for your classic repo. This can be found under repository Settings / Integrations / GitHub Pull Requests. Deselect "active" and click "save". Finally, enable pull request integration for your new repository.

Switching to Engines-based Analysis