Conversation
9b1efd5 to
78acfb4
Compare
|
|
||
| release := options.Selection.Release | ||
| targetDir := filepath.Clean(options.TargetDir) | ||
| targetDirAbs := targetDir |
There was a problem hiding this comment.
[Note for reviewer]: There was an edge case caught by spread where the relative path where causing the report to misbehave and not add the mutated files. I have changed the test with relative paths in slicer_test.go to fail (regression test).
This happened because targetDir was used inconsistently together with targetDirAbs, that's why I have changed it so all the code in slicer uses the absolute version and there are no edge cases that we have to test separately.
The paths with ``mutable: true`` property can be "mutated" with mutation scripts. Thus, the files matching those paths may have a different size and hash after the mutation scripts have been run. The report should reflect these changes by updating the entries of the mutated paths. Paths can also have the ``until: mutate`` property. This means that those files are available until the mutation scripts have been run and are not present in the final file system. Thus, they should not be part of the report either. This commit adds support for both -- it updates the changed properties of mutated files and makes sure not to add report entries for ``until: mutate``.
db70406 to
a3abd95
Compare
|
Apologies for force pushing, there was a problem with the authoring of one of the commits because Github rewrote Rafid's email when working on my fork and commiting. I have had to change it and force push to get the CLA passing. |
niemeyer
left a comment
There was a problem hiding this comment.
This is going in a good direction, Alberto, thanks.
Here is a first pass.
internal/slicer/report.go
Outdated
| } | ||
|
|
||
| if entry, ok := r.Entries[relPath]; ok { | ||
| if entry, ok := r.Entries[path]; ok { |
There was a problem hiding this comment.
The logic here used relative paths and absolute paths intentfully, for security but also clarity on the user interface. Note how we only reported the out-of-root issue independently, but then all the details below are inside the root path, and thus nicely short and clear. The variables were also aptly named to reduce the chances of mistakes while using them. All of this was careful design, and it doesn't look like the motivation for this PR requires touching these details.
There was a problem hiding this comment.
Are you suggesting changing the name back to relPath that is indeed more informative?
If you are talking about the refactor into sanitizePath, I think having it as a separate function has value because we want the logic to be the same across all entry points to the report (Add and Mutate), this way we can change the logic in one place with no possibility for drift.
Maybe what we need to do is change the name of sanitizePath to something more informative.
There was a problem hiding this comment.
Discussed this offline. There was a misunderstanding that we were no longer using relative path for the report itself and for error reporting, that could indeed be a major flaw and lead to some nasty bugs. However, that was not the case, the problem was that we renamed the path variable and it was no longer clear which one was relative and which one absolute. We have now changed the names to:
relPath, err := r.sanitizeAbsPath(fsEntry.Path, fsEntry.Mode.IsDir())
which hopefully makes it clear that fsEntry.Path is an absolute path and that we get back a relative one.
niemeyer
left a comment
There was a problem hiding this comment.
Thanks, Alberto. One more pass.
internal/slicer/report.go
Outdated
| relPath = relPath + "/" | ||
| relPath, err := r.sanitizeAbsPath(fsEntry.Path, fsEntry.Mode.IsDir()) | ||
| if err != nil { | ||
| return fmt.Errorf("cannot add path: %s", err) |
There was a problem hiding this comment.
Per last conversation/review, these errors need tuning so we can understand what they're trying to convey, and also so that they are more consistent with each other. For example:
"cannot add path to report: %s"
"cannot mutate path in report: %s"
"cannot mutate path in report: %s not previously reported"
"cannot mutate path in report: %s is a directory"
There was a problem hiding this comment.
Agree with one minor change reported -> added in:
cannot mutate path in report: %s not previously added
to make it more accurate with the report API of Add and Mutate.
niemeyer
left a comment
There was a problem hiding this comment.
Looks good, except for the regression on Mode.
| } | ||
|
|
||
| // dumpFSEntry returns the file entry in the same format as [testutil.TreeDump]. | ||
| func dumpFSEntry(fsEntry *fsutil.Entry, root string) map[string]string { |
There was a problem hiding this comment.
[Comment for reviewer] Now it is redundant, better to unify it with testutils.TreeDumpEntry.
niemeyer
left a comment
There was a problem hiding this comment.
This is looking good, thanks Alberto.
A few minor points for our consideration.
| options: fsutil.CreateOptions{ | ||
| Path: "foo", | ||
| // Mode should be ignored for existing entry. | ||
| Mode: 0644, |
There was a problem hiding this comment.
This sounds correct for the context of this PR, but not in the context of a cut being done from the ground up. So we need to dig down a bit and find out the background here in more detail. For example, if we somehow have a dirty filesystem, we don't want to ignore the fact that it was dirty and potentially with a completely wrong mode, and then ship an image that reports a wrong mode as if it was correct.
There was a problem hiding this comment.
As we agreed offline, we will follow up on this issue on another PR once we have dived deep into how overlayfs and docker works to correctly create the different layers.
|
|
||
| release := options.Selection.Release | ||
| targetDir := filepath.Clean(options.TargetDir) | ||
| targetDirAbs := targetDir |
The paths with
mutable: trueproperty can be "mutated" with mutationscripts. Thus, the files matching those paths may have a different size
and hash after the mutation scripts have been run. The report should
reflect these changes by updating the entries of the mutated paths.
Paths can also have the
until: mutateproperty. This means thatthose files are available until the mutation scripts have been run and
are not present in the final file system. Thus, they should not be part
of the report either.
This commit adds support for both -- it updates the changed properties
of mutated files and makes sure not to add report entries for
until: mutate.