Github Actions中Ruby on Rails CI执行Rubocop报错：command not found

1. 直接执行rubocop --parallel报command not found（退出码127）的原因 #

当你开启bundler-cache: true时，GitHub Actions的Rails工作流会复用Bundler的缓存来加速依赖安装，但CI环境里Bundler默认不会把gem的可执行文件路径（比如rubocop所在的vendor/bundle/bin）添加到系统PATH里。

• 你本地能直接运行rubocop，是因为bundle install时已经把可执行文件软链到了用户目录bin或系统bin目录，系统能找到命令；但CI环境没有这个自动配置，直接敲命令自然找不到。

2. 改用bundle exec rubocop --parallel出现rubocop-discourse错误的原因 #

这是依赖解析不匹配导致的：

• rubocop-discourse是某个间接依赖（可能是你项目里的其他gem，或者rubocop-rails的依赖）引入的，但你的Gemfile里没显式声明它，且本地的Gemfile.lock可能也没记录这个依赖的正确版本。
• 开启bundler-cache: true后，CI会严格按照本地推送的Gemfile.lock来安装依赖，一旦lock文件里没有rubocop-discourse的记录，或者版本不兼容，bundle exec就会因为找不到这个依赖报错。而本地环境可能因为之前手动装过这个gem，或者Bundler的本地解析逻辑更宽松，所以没触发这个问题。

3. 移除bundler-cache: true或手动装gem就能正常运行的原因 #

• 移除bundler-cache: true后，工作流会重新执行完整的bundle install，这个过程中Bundler会重新解析所有依赖（包括间接依赖），同时会临时把gem的可执行文件路径加入CI环境的PATH，所以既解决了命令找不到的问题，也补全了缺失的间接依赖。
• 手动安装rubocop相关gem则是直接绕过Bundler的缓存机制，把需要的可执行文件和依赖直接装到CI环境里，自然能正常运行。

内容的提问来源于stack exchange，提问作者Rafael Moreira