`Rails/Output` and `Rails/Exit` behavior differs depending on directory structure

[mizoR]

We’ve encountered a situation where Rails/Output and Rails/Exit behave differently depending on the environment in which RuboCop is run.
Specifically, some files are linted in certain environments but not in others, even though the project content is the same.

Expected behavior

I think that Include and Exclude path patterns for cops like Rails/Output and Rails/Exit should be evaluated relative to the directory where the .rubocop.yml file resides. This would ensure consistent linting results regardless of the absolute location of the project on the filesystem or the environment where RuboCop is run.

Actual behavior

When running RuboCop in different environments where the project is mounted or checked out in different absolute paths (e.g., /app inside Docker vs. ~/Projects/myapp on macOS), the Include patterns such as **/app/**/*.rb seem to match different files. As a result, cops like Rails/Output or Rails/Exit detect offenses in some environments but not others, causing inconsistent linting results.

ref:

• default.yml - Rails/Exit > Include
  • https://github.com/rubocop/rubocop-rails/blob/1126d68/config/default.yml#L497
• default.yml - Rails/Output > Include
  • https://github.com/rubocop/rubocop-rails/blob/1126d68/config/default.yml#L760

Steps to reproduce the problem

1. Place a file with puts or exit in bin/ or another directory inside your project.
2. Run RuboCop on two environments with different project root paths, e.g.:
   • ~/Projects/app
   • ~/Projects/myapp
3. Observe that the file in bin/ is flagged in app but not myapp

Small example is: https://github.com/mizoR/rubocop-rails-1487

RuboCop version

$ bundle exec rubocop -V                                                                                                                                                                                                                                                                                                                                                                          rbenv:3.4.4 
1.75.8 (using Parser 3.3.8.0, Prism 1.4.0, rubocop-ast 1.44.1, analyzing as Ruby 3.4, running on ruby 3.4.4) [arm64-darwin24]
  - rubocop-rails 2.32.0

[Aqualon]

Side-effect of #1476

[hirakuro]

I'm facing same problem on GitLab Runner, that places a working directory for build at /var/lib/gitlab-runner/builds/(SNIP)/project.
This directory is matched with a default Include pattern **/lib/**/*.rb of the rule "Rails/Output", so every files are applied this rule.

[tdeo]

Hello,

While I understand the situation really degraded for a couple of cops, it's underlying root cause seem to origin from rubocop/rubocop@e921a2c during which it was decided to also run Exclude patterns agains absolute path and not only relative paths, which from the commit message seemed like a workaround for a prior transformation of Exclude patterns. I think we need to open an upstream issue to rubocop itself to address the fact that it doesn't make much sense that anything beyond the repo root influences the way rubocop behaves.

I believe the issue never arose before because all internal rubocop patterns listed in https://github.com/rubocop/rubocop/blob/master/config/default.yml use glob wildcards either at the begining, or at the end, but neither both, the situation happening here is thus never happening in classic use-cases.

[tdeo]

As for a fix in the meantime before discussing that upstream, I'd happily change the Include / Exclude patterns to packs/**/app/**/*.rb instead of **/app/**/*.rb which won't be matching any absolute paths anymore. While I think this would work pretty straightforwardly for packwerk and canonical packs location, I'm unsure how projects that utilize engines tend to organize them.

[adamkiczula]

I ran into this same issue where running tests in CI and docker where my code lives in /app caused the Rails cops to apply unexpectedly.

@tdeo I think it makes sense short term to pick a few common options (maybe engines and plugins? Disclaimer: I also don't use engines, that just seems to be the pattern I saw googling for examples) in addition of course to packs for packwerk. I'd be happy to make a contribution if this makes sense.

I did see that there is also an upstream issue open (rubocop/rubocop#14361), but it hasn't seen any activity as of yet.