Hash main.wasm and not the package #574
Conversation
f1cb094 to
e0c5517
Compare
There was a problem hiding this comment.
So some initial feedback.
I was thinking maybe we could instead have the validate function accept an optional callback function. So that the validate.go file could continue to call validate() as normal and there will be no change to the interface or the return values.
But for deploy.go it can call validate() and pass a callback function which is passed the main.wasm file as an io.Reader so we can do the hashing stuff as a separate function.
e.g.
type FileValidator func(io.Reader)
func HashSum(r io.Reader) {
// hash generation
}
func validate(path string, fvs ...FileValidator) error {
...
}
// validate.go
validate("/some/path")
// deploy.go
validate("/some/path", HashSum)This would make the change set smaller, and also mean the validate() function avoids doing too much.
4804bb0 to
19784db
Compare
|
I've updated the PR based on your feedback. I went for rebase to make things simpler for me but you can see the changes from the original PR here: https://github.com/fastly/cli/compare/5f058435994336ba942678f8e2f9c5165f577548..fgsch/issue_243 Let me know what you think. |
pkg/commands/compute/validate.go
Outdated
| if fileValidator != nil { | ||
| err = fileValidator(f) | ||
| } | ||
|
|
||
| closeErr := f.Close() | ||
|
|
||
| if err != nil { | ||
| return fmt.Errorf("error closing package: %w", err) | ||
| return err | ||
| } | ||
| if closeErr != nil { | ||
| return fmt.Errorf("error closing file: %w", closeErr) |
There was a problem hiding this comment.
I think the if err != nil check can be moved inside of the if fileValidator != nil statement,
and closeErr renamed to just err.
So something like:
if fileValidator != nil {
if err := fileValidator(f); err != nil {
return err
}
}
err = f.Close()
if err != nil {
return fmt.Errorf("error closing file: %w", err)
}There was a problem hiding this comment.
The reason for this is to avoid having to call f.Close() in two different places.
Are you saying that you want to omit the call entirely, or are you happy with the call being within the fileValidator error path?
There was a problem hiding this comment.
To be clear, the alternative I wanted to avoid was:
if fileValidator != nil {
if err := fileValidator(f); err != nil {
f.Close()
return err
}
}There was a problem hiding this comment.
OK that's understandable. I actually missed the fact that you would have had to close in two places.
So what would be the practical outcome of not closing the file when we're in a CLI environment? My understanding is the moment the process stops the associated file descriptors will be automatically cleaned up.
If this was a long running server process, then I'd agree to always explicitly calling f.Close() but for a CLI I don't think it matters as much.
Also from a user experience, I personally don't feel it's a useful error to report back as a user can't do anything about it if it did fail so maybe if we do want to close the file we instead use defer and just report it into the error log using c.Globals.ErrLog.
There was a problem hiding this comment.
I think the same could be said about many paths in the code.
Let's just keep the Close call for completeness but ignore the error as in the snippet above.
This moves the hash calculation at validate() tim to avoid opening the package twice. Fixes #243.
This moves the hash calculation into validate(), now validateAndHash(),
to avoid opening the package twice.
Fixes #243.