Skip to content

gemfile:false option no longer behaves as expected in YAML config #862

Closed

Description

@arthurthefourth

As of 0.65, when I run overcommit with gemfile: false in the config, I get the following error:

Problem loading 'false': my-code-directory/false not found

It seems like when #859 started using regex to parse the gemfile config instead of YAML, we ended up losing some nice YAML.parse functionality?

# .overcommit.yml
gemfile: false

# hook code
config = File.read('.overcommit.yml') =~ /gemfile: ['"]?(.*)['"]?/
gemfile = Regexp.last_match(1) # gemfile is now set to the (truthy) string "false"

if gemfile # this is triggered with gemfile = 'false'
  ENV['BUNDLE_GEMFILE'] = gemfile

  begin
    Bundler.setup
  rescue Bundler::BundlerError => e
    puts "Problem loading '#{gemfile}': #{e.message}" # Problem loading 'false'
    puts "Try running:\nbundle install --gemfile=#{gemfile}" if e.is_a?(Bundler::GemNotFound)
    exit 78 # EX_CONFIG
  end
end

Activity

  1. sds commented on Feb 3, 2025

    @sds
    Owner

    Heads up @xjunior: looks like this was introduced by #859.

  2. pilaf commented on Feb 7, 2025

    @pilaf
    Contributor

    Having a similar problem since we had this line in our .overcommit.yml:

    gemfile: Gemfile # enforce bundled version of overcommit

    And now overcommit doesn't strip out the inline comment, resulting in this weird looking error message:

    Problem loading 'Gemfile # enforce bundled version of overcommit': /path/to/project/Gemfile # enforce bundled version of overcommit not found
    
  3. added a commit that references this issue on Feb 16, 2025
    3db733e
  4. mattbrictson commented on Feb 16, 2025

    @mattbrictson
    Contributor

    @pilaf I fixed the gemfile: false issue, but not the inline comment problem that you mentioned. You might want to open a separate issue for that.

  5. pilaf commented on Feb 17, 2025

    @pilaf
    Contributor

    @mattbrictson Thanks.

    The issue in itself is not a big deal obviously since the comment can just be moved to the line above (which is what I did), but when I first encountered it I wasn't aware that overcommit was parsing that line on its own and the error message threw me down a misguided path of thinking Psych had changed how it parsed inline comments until I found this issue.

    Perhaps a little comment in default.yml would be enough? I've opened a small PR for it: #865, but feel free to discard it of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions