Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Allow globs in FPM unix socket paths #7089
Allow globs in FPM unix socket paths #7089
Changes from 3 commits
b74c7aa
bff2d92
916f1d3
a57b771
8455e2c
b177094
2a7bf89
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm not sure I understand this correctly, would this check for files that contain '*' characters? I feel like this is probably not needed, this seems very edge case, but either way we should consider if it should be an error to not match a socket. In the other plugins using globs, not having matches is generally not an error but this decision it can make it difficult to debug. If there are situations where it is normal to not match a socket, then it might be better to ignore the error.
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.
I did it this way to keep the previous behavior, which is to error out on nonexistent socket paths. Since
filepath.Glob
ignores any errors other than syntax ones, I've usedos.Stat
to get the appropriate error. The special handling ofos.ErrNotExist
is there because it's also done elsewhere in the plugin.If you think we consider that not matching any sockets is not an error, this code would indeed be a bit cleaner.
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.
One example of where this handling is useful is when the unix socket path is in fact not a glob, and the file does not exist. In that case, we'd get an empty slice of strings as a result from the glob, with no error, so this extra checking restores the error message one would get before glob support.
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.
Okay, let's continue to show an error when the socket doesn't exist. I think we should then remove the Stat call on L166, which doesn't seem useful anymore and anyway we will report an error afterwards connecting to the socket if it doesn't exist.
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.
Looking at the
globpath
module I noticedMatch
actually returns the given parameter when it's a static path, so the latest commit handles this case correctly now. I've also removed the redundantos.Stat
call.If the PR is OK now, do you want me to rebase before merging?