Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
arthurthefourth opened this issue Jan 30, 2025 · 4 comments · Fixed by #863
Closed

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

arthurthefourth opened this issue Jan 30, 2025 · 4 comments · Fixed by #863
Labels

Comments

@arthurthefourth
Copy link

arthurthefourth commented Jan 30, 2025

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
@sds
Copy link
Owner

sds commented Feb 3, 2025

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

@sds sds added the bug label Feb 3, 2025
@pilaf
Copy link
Contributor

pilaf commented Feb 7, 2025

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

@sds sds closed this as completed in #863 Feb 16, 2025
sds pushed a commit that referenced this issue Feb 16, 2025
Setting `gemfile: false` in `.overcommit.yml` is supposed to disable
Bundler. However, a recently-introduced bug causes `false` to be
interpreted as the name of the gemfile. Bundler looks for a gemfile
named "false", which fails, leading overcommit's hooks to crash.

This PR fixes the bug by adjusting the regex used to parse the
`gemfile:` line in the config. Now, `false` is no longer interpreted as
a gemfile name.

I added an integration test to verify the fix.

Fixes #862
@mattbrictson
Copy link
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.

@pilaf
Copy link
Contributor

pilaf commented Feb 17, 2025

@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.

sds pushed a commit that referenced this issue Feb 19, 2025
…t.yml (#865)

Related to #863 and [this
comment](#862 (comment)):

> Having a similar problem since we had this line in our
`.overcommit.yml`:
> 
> ```yaml
> 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
> ```

I think adding support for comments in the `gemfile:` regexp is likely
overkill and may still not be enough when the next person tries to use
yet another YAML feature in that line, but perhaps this little warning
would help someone else avoid tripping.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants