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:
A few grade-related things to keep in mind when enabling our engines analysis:
Config file: On our platform, you'll specify which files you want graded using your
.codeclimate.ymlfile, 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.
- From your repo, mouse over the repository's name and click Settings.
- Select the Code Climate engines tab.
- 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.
When using the Code Climate Engines, the analysis results come from the individual engines that you enable in your
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.
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.
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.
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.
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.
On our new platform, we have implemented a Duplication engine.
Clarity / Bug Risk:
Our PHP Mess Detector engine also detects code smells and possible errors.
On our new platform, we have implemented a Duplication engine that analyzes php code.
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:
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.