Hey, there! 👋

This project is done in terms of features. If the project is severely broken due to a change in GitHub or RuboCop, it will be archived at that time and left to those that care about it to fork, fix, and maintain.

I will be happy to review your pull request, but will not be adding any more myself, and make no guarantees I will accept anything that adds behavior. Please read the introduction for my thoughts on why you should not use this action.

This being said, I will be happy to give you contributor access if you're interested in becoming a maintainer. If I don't respond within a day or two through issues, you may email me (for this reason only) or DM me on Twitter. Truthfully this project makes me feel very burnt out whenever I am around it, especially since I have not actually used it in months.

Thanks for understanding,

-- @andrewmcodes

RuboCop Linter Action is a GitHub Action to run RuboCop against your Ruby codebase and output the results in the GitHub Checks UI.

IMPORTANT: The Checks API only looks for pushes in the repository where the check suite or check run were created. Pushes to a branch in a forked repository are not detected and return an empty pull_requests array.

This is straight out of GitHub's documentation.

Put simply, this action will not work on pull requests from a forked repository, making it basically useless for open source repositories.

PLEASE DO NOT USE THIS ACTION, and instead follow the Rails way.

IMPORTANT: This action does not run bundle install by default. In order to install gems via bundler, you will need to update your configuration file. See more below.

The default usage, similar to running gem install rubocop && rubocop from your command line:

- name: RuboCop Linter Action
  uses: andrewmcodes/[email protected]
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

This GitHub Action provides a way to easily run RuboCop on your codebase, and output the results to the view via GitHub Checks

While it is recommended to write a custom GitHub Action to run RuboCop on your codebase, this action takes that functionality one step further using Checks. After the RuboCop Linter Action runs RuboCop against your Ruby code, it will create annotations that you can easily view in the GitHub UI, matched up with the offending code.

At this point the Checks API has been in beta over two years, and it is still possible that there will be breaking API changes that affect this action. If this occurs, please open a pull request to fix it.

Are you sure you need this action?

I would truly recommend not using this action. The potential for random breaking changes from GitHub will always be a looming threat and I have ascertained people are using this action as a crutch to avoid what they really ought be doing.

If you find yourself constantly having to wade through RuboCop errors in GitHub, the fix is to not allow them to get to GitHub broken in the first place. I would highly suggest using a tool like lefthook or similar to flag or fix failing cops before they get to GitHub Actions, saving you and your team time and removing the need for this action.

• RuboCop Linter Action
  • Quickstart
  • Introduction
  • Usage
    • Screenshots
    • Configuration
    • Inputs
    • Simple Config
    • Default Config
    • Version Constraints
    • Spec
    • Usage
    • Example Workflow
    • Updates
    • RuboCop Docs
    • FAQ
  • Config options
    • exit_on_failure
  • Community
    • Changelog
    • Contributing
    • Code of Conduct
    • License

action_config_path

Defintion

The only input accepted for the action, which allows you to specify a custom location for the action config file.

Default

.github/config/rubocop_linter_action.yml

This is simple config file showing how you could choose to change the version numbers, but use defaults for the rest:

# .github/config/rubocop_linter_action.yml

versions:
  - rubocop-rails
  - rubocop-performance: "1.5.1"
  - rubocop-minitest: "latest"
  - rubocop-rspec: "1.37.0"

# .github/config/rubocop_linter_action.yml

# Description: The name of the check that will be created.
# Valid Options: A reasonably sized string.
# Default: 'RuboCop Action'
check_name: "RuboCop Results"

# Description: Versions required to run your RuboCop checks.
# Valid options: RuboCop and any RuboCop extension, by default the latest gem version will be used. You can explicitly state that
# (not required) or use a version number, like '1.5.1'.
# Default:
#   versions:
#     - rubocop: 'latest'
versions:
  - rubocop
  - rubocop-rails
  - rubocop-minitest
  - rubocop-performance: "1.5.1"
  - rubocop-rspec: "1.37.0"

# Description: RuboCop configuration file path relative to the workspace.
# Valid options: A valid file path inside of the workspace.
# Default: nil
# Note: This does not need to be filled out for RuboCop to still find your config.
# Resource: https://rubocop.readthedocs.io/en/stable/configuration/
rubocop_config_path: ".rubocop.yml"

# Run all cops enabled by configuration except this list.
# Valid options: list of valid cop(s) and/or departments.
# Default: nil
# Resource: https://rubocop.readthedocs.io/en/stable/cops/
rubocop_excluded_cops:
  - "Style/FrozenStringLiteralComment"

# Minimum severity for exit with error code
# Valid options: 'refactor', 'convention', 'warning', 'error', or 'fatal'.
# Default: 'warning'
# Resource: https://rubocop.readthedocs.io/en/stable/configuration/#severity
rubocop_fail_level: "warning"

# Whether or not to use --force-exclusion when building the rubocop command. Use this if you are only linting modified
# files and typically excluded files have been changed. For example, if you exclude db/schema.rb in your rubocop.yml
# but a change gets made, then with the check_scope config set to 'modified' rubocop will lint db/schema.rb. If you set
# this to true, rubocop will ignore it.
# Valid options: true || false
# Default: false
rubocop_force_exclusion: true

# Instead of installing gems from rubygems, we can run `bundle install` on your project,
# you would need to do this if you are using something like 'rubocop-github' or if you don't
# want to list out dependencies with the `versions` key.
# Valid options: true || false
# Default: false
bundle: false

# The scope of code that RuboCop should lint. Use this if you only want to lint changed files. If this is not set
# or not equal to 'modified', RuboCop is run against the entire codebase. Note that this will not work on the master branch.
# Valid options: 'modified'
# Default: nil
check_scope: "modified"

# The base branch against which changes will be compared, if check_scope config is set to 'modified'.
# This setting is not used if check_scope != 'modified'.
# Valid options: 'origin/another_branch'
# Default: 'origin/master'
base_branch: "origin/master"

It is highly recommend you tie yourself to a version and do not do the following. I promise your life will be much easier. 😇

# ❌ Bad, use at your own risk!
uses: andrewmcodes/rubocop-linter-action@master

# ✅ Good
uses: andrewmcodes/[email protected]

action_config_path:
  description: "Define a path to your optional action config file."
  required: false
  default: ".github/config/rubocop_linter_action.yml"

with:
  action_config_path: ".github/actions/config/rubocop.yml"

Here is an example workflow file incorporating RuboCop Linter Action with customized usage based on the values in your configuration file:

name: Linters

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: RuboCop Linter
        uses: andrewmcodes/[email protected]
        with:
          action_config_path: ".github/config/rubocop_linter_action.yml" # Note: this is the default location
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Since the action will default to the latest RuboCop release, you may run into isues with outdated config options that are specified in your .rubocop.yml. To easily upgrade your config, use mry.

Several of the config options map directly to RuboCop's inputs. Check their documentation for help or more info.

If you cannot find an answer here that you think should be included, let us know!!

1. Why is my check result being shown under the wrong header?

There is a bug with Checks that might cause your runs to get jumbled in the UI, but they will all still run and render annotations in the diff correctly. Hopefully this will get fixed or we figure out that we are doing something wrong that is fixable.

2. How come I can't create checks on forked repositories? (example)

NOTE: The Checks API only looks for pushes in the repository where the check suite or check run were created. Pushes to a branch in a forked repository are not detected and return an empty pull_requests array.

This is straight out of GitHub's documentation. Put simply, this action won't work correctly on pull requests from a forked repository as is.

I am open to a PR that will just output the results of the RuboCop run to the actions log if someone would like to take a shot at adding that!

3. The modified flag is not working!

If you specify the following in your config file:

check_scope: "modified"

Please note that this will not work on commits to master. If you have an idea on how to make this work, please open an issue or PR!

4. My GitHub Checks results don't match the output of running RuboCop locally.

Make sure you're running the same version of RuboCop that the linter is using. If using Bundler, try running bundle update rubocop. If you need the linter to use an older version, you can specify it in the config file:

versions:
  - rubocop: "0.88.0"

Stop the workflow execution if the linter returns some failures.

- name: RuboCop Linter Action
  uses: andrewmcodes/[email protected]
  with:
    exit_on_failure: true
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

View our Changelog

If you would like to contribute, please limit to bug fixes. At this point, you will need to use your own fork if you want a big change in behavior.

Please make sure to read the code of conduct before submitting issues or pull requests.

To lend a helping hand:

• Fork the repository
• Make your desired changes
• Create a pull request
• Ensure tests are passing

Include [ci skip] in your commit message if the change does not change the meaning of code (e.g., documentation updates).

Code of Conduct

MIT