Skip to content
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

Reconcile history from image manifest and config #17

Merged
merged 3 commits into from
Oct 7, 2018

Conversation

wagoodman
Copy link
Owner

Pulling history from the docker API doesn't make sense for two reasons:

  • the API does not include empty_content bool, and inferring this from the created_by attribute is not accurate (sometimes a layer with content has a created_by attribute that starts with a nop statement).
  • we already have the necessary information from the image.tar that we've saved

Downside is that we have to calculate the layer size manually, but since we're already iterating across all contents, I don't see the harm. The upside is that we're not coupling to a docker API type?

This will require further cleanup.

filetree/tree.go Outdated
@@ -20,6 +20,7 @@ const (
type FileTree struct {
Root *FileNode
Size int
FileSize int64
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use uint64 here? The value can't be negative...

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

fmt.Println(err)
os.Exit(1)
}
defer tarFile.Close()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the defer tarFile.Close() be immediately after os.Open()? Is there any situation where the code gets a file handle but then exits 1 before closing it?

Copy link
Owner Author

@wagoodman wagoodman Oct 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not certain if there is a case where the file is open before exit is called, however, I still think this is the preferred way to go for a couple reasons:

  1. os.Exit cleans up file descriptors (in case the file was open but there was another error)
  2. since we're not guaranteed to have an open file we shouldn't attempt to close it until after we've checked it was opened with no error.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense.

@wagoodman wagoodman merged commit 9625c51 into master Oct 7, 2018
@wagoodman wagoodman deleted the reconsile-history branch October 7, 2018 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants