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

SwiftLint is picking the wrong configuration #1744

Closed
marcelofabri opened this Issue Aug 3, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@marcelofabri
Collaborator

marcelofabri commented Aug 3, 2017

I have a .swiftlint.yml that I've used to reproduce #1586 on my home folder. When running swiftlint inside a subdirectory (that has a configuration file), it's loading the configuration from my home dir.

This happens even if I use --config. Tested with 0.21.0.

This only happens when using --path. And the weird thing is that SwiftLint even prints that it's using the right configuration:

$ swiftlint lint --path file.swift  --config /Users/marcelofabri/dev/SwiftLint/.swiftlint.yml --no-cache
Loading configuration from '/Users/marcelofabri/dev/SwiftLint/.swiftlint.yml'
Linting Swift files at path file.swift
Linting 'file.swift' (1/1)
Invalid configuration for custom rule 'two_enters_before_marks'.
Done linting! Found 0 violations, 0 serious in 1 file.
@mergesort

This comment has been minimized.

Show comment
Hide comment
@mergesort

mergesort Aug 4, 2017

If you need any more info, I'm seeing this too. Specifically the configuration that's being picked is pointing to your home directory.

Could not read configuration file at path '/Users/mergesort/Documents/Projects/Picks/.swiftlint.yml': file /Users/marcelofabri/projetos/SwiftLint/Source/SwiftLintFramework/Models/Configuration.swift, line 129

mergesort commented Aug 4, 2017

If you need any more info, I'm seeing this too. Specifically the configuration that's being picked is pointing to your home directory.

Could not read configuration file at path '/Users/mergesort/Documents/Projects/Picks/.swiftlint.yml': file /Users/marcelofabri/projetos/SwiftLint/Source/SwiftLintFramework/Models/Configuration.swift, line 129
@marcelofabri

This comment has been minimized.

Show comment
Hide comment
@marcelofabri

marcelofabri Aug 5, 2017

Collaborator

@mergesort Thanks for the info. This indeed would happen with this bug. Could you try using #1745 to see if the issue still persists?

Collaborator

marcelofabri commented Aug 5, 2017

@mergesort Thanks for the info. This indeed would happen with this bug. Could you try using #1745 to see if the issue still persists?

@SDGGiesbrecht

This comment has been minimized.

Show comment
Hide comment
@SDGGiesbrecht

SDGGiesbrecht Aug 5, 2017

Contributor

And the weird thing is that SwiftLint even prints that it's using the right configuration.

Are you sure you are not using master? master’s current merge logic would find the right file (printing the message you noted) and then silently load and merge itself into anything in each parent directory until it hits the project root.

Since --config can be outside the project, it will never hit the root and go all the way to the system root instead.

--path may be setting the project root as a file path, and since the search logic looks folder by folder, it never hits the file and also merges all the way back to the system root.

This would all make a lot of sense, but not if the bug really was already there in 0.21.0.

I noted a bunch of related merging bugs and quirks in the notes for #1748 (and dealt with some of them during the refactor). Maybe some of that information will be useful.

Contributor

SDGGiesbrecht commented Aug 5, 2017

And the weird thing is that SwiftLint even prints that it's using the right configuration.

Are you sure you are not using master? master’s current merge logic would find the right file (printing the message you noted) and then silently load and merge itself into anything in each parent directory until it hits the project root.

Since --config can be outside the project, it will never hit the root and go all the way to the system root instead.

--path may be setting the project root as a file path, and since the search logic looks folder by folder, it never hits the file and also merges all the way back to the system root.

This would all make a lot of sense, but not if the bug really was already there in 0.21.0.

I noted a bunch of related merging bugs and quirks in the notes for #1748 (and dealt with some of them during the refactor). Maybe some of that information will be useful.

@marcelofabri

This comment has been minimized.

Show comment
Hide comment
@marcelofabri

marcelofabri Aug 5, 2017

Collaborator

Are you sure you are not using master?

Yes.

Collaborator

marcelofabri commented Aug 5, 2017

Are you sure you are not using master?

Yes.

@SDGGiesbrecht

This comment has been minimized.

Show comment
Hide comment
@SDGGiesbrecht

SDGGiesbrecht Aug 5, 2017

Contributor

Hmm... all very strange. But I guess that is the nature of bugs. [sigh]

Contributor

SDGGiesbrecht commented Aug 5, 2017

Hmm... all very strange. But I guess that is the nature of bugs. [sigh]

marcelofabri added a commit that referenced this issue Aug 17, 2017

marcelofabri added a commit that referenced this issue Aug 17, 2017

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