-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Adds --working-directory
command line option
#5560
Adds --working-directory
command line option
#5560
Conversation
Generated by 🚫 Danger |
@@ -26,6 +26,11 @@ enum LintOrAnalyzeMode { | |||
|
|||
struct LintOrAnalyzeCommand { | |||
static func run(_ options: LintOrAnalyzeOptions) async throws { | |||
if let workingDirectory = options.workingDirectory { | |||
if !FileManager.default.changeCurrentDirectoryPath(workingDirectory) { | |||
throw Issue.couldNotChangeToWorkingDirectory(path: workingDirectory) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So originally this throw
produced the following eventual output:
Error: couldNotChangeToWorkingDirectory(path: "Source/SwiftLintt")
because the thrown error eventually gets passed to MessageInfo(error: Error, type: ParsableArguments.Type)
from the swift-argument-parser
. Ideally it would get caught there by
case let error as LocalizedError where error.errorDescription != nil:
self = .other(message: error.errorDescription!, exitCode: .failure)
but it was not, because Issue
's implementation of errorDescription
(var errorDescription: String
) does not match the LocalizedError
protocol requirement (var errorDescription: String?
).
I've fixed that, but because of the way the thrown error is now printed, we get
Error: warning: Could not change working directory to 'Source/SwiftLintt'.
One way around that would just be to brute-force:
if !FileManager.default.changeCurrentDirectoryPath(workingDirectory) {
Issue.couldNotChangeToWorkingDirectory(path: workingDirectory).print()
exit(2)
}
Another possibility would be to remove our warning:
and error:
prefixes from errorDescription
, but to add them back in Issue.print()
- most usages look like that would be ok, but I'm not sure how confident I am that all of them would be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to SwiftLintError.usageError
, which produces: `Error: Could not change working directory to 'Source/SwiftLintt'
I would kind of expected. throwing an Issue
to work though.
--working-directory
command line option
@@ -235,7 +235,7 @@ public struct Configuration { | |||
if useDefaultConfigOnFailure ?? !hasCustomConfigurationFiles { | |||
// No files were explicitly specified, so maybe the user doesn't want a config at all -> warn | |||
queuedPrintError( | |||
"\(Issue.wrap(error: error).errorDescription) – Falling back to default configuration" | |||
"\(Issue.wrap(error: error).errorDescription ?? "") – Falling back to default configuration" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what a good default is here
140674c
to
5d44cb4
Compare
508ac7f
to
4eb238d
Compare
Co-authored-by: Danny Mösch <[email protected]>
6d9a9ad
to
99fa889
Compare
Adds a
--working-directory
argument tolint
andanalyze
, for users who cannot easily control the current directory when executing SwiftLint (e.g. in some plugin and CI scenarios).Addresses #5424
This is required because
.swiftlint.yml
's in the current directory are treated slightly differently to.swiftlint.yml
's found deeper in the tree.For example:
We could assume that the first
.swiftlint.yml
we encountered was the "main" one, but this would not be true in the unusual, but valid case, where users intentionally did not have a "main".swiftlint.yml
. Additionally, some SwiftLint code, specifically some reporters, assume that the current directory is also the top-level directory of the project.All relative paths on the command line and in configuration files will be treated as relative to the specified working directory.