-
Notifications
You must be signed in to change notification settings - Fork 1k
Skip broken vendor symlink rather than returning an error. #1191
Conversation
internal/gps/strip_vendor.go
Outdated
@@ -22,11 +22,7 @@ func stripVendor(path string, info os.FileInfo, err error) error { | |||
} | |||
|
|||
if (info.Mode() & os.ModeSymlink) != 0 { | |||
realInfo, err := os.Stat(path) | |||
if err != nil { |
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.
Rather than simply ignoring errors here, let's verify that it's an error indicating that the target file does not exist.
(I'm still thinking about this change overall, but if we do go this direction, then we absolutely need this check.)
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 guess adding err != nil { do_nothing } is not necessary. it ignores when lstat() succeed but stat() is either returns null or non-directory. What checks would you like to add specifically?
This is a case our whole team had to rollback.
@sdboyer, what are your concerns on skipping broken |
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.
sorry, yes, i wasn't thinking clearly about the implications here. this is definitely fine.
What does this do / why do we need it?
Skip broken vendor symlink rather than returning an error
What should your reviewer look out for in this PR?
When one of 3rd party packages has a broken vendor symlink, it fails whole ensure process.
Current logic behaves:
I think this behavior is not intended and it seems to be that it's better to skip the check except the case it's linked to a valid directory as it's harmless rather than returning an error causing the whole process stop.
Expected/New behavior:
Do you need help or clarification on anything?
No
Which issue(s) does this PR fix?
This is a new behavior introduced in v0.3.1 with its improved type checking
Since this is a breaking change, some users migrating from 0.3.0 could experience this issue.
The main problem is that when this happens on some 3rd party libraries that you don't have the control, you just have to downgrade and use v0.3.0