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

Getters refactoring #255

Merged
merged 113 commits into from
Jun 4, 2020
Merged

Getters refactoring #255

merged 113 commits into from
Jun 4, 2020

Conversation

sylviamoss
Copy link

@sylviamoss sylviamoss commented May 28, 2020

This is an extension of #240.

Client refactoring

The PR refactors the client code to make it try all valid Getters for a given source string. Each Getter will try to detect a valid source string and if the detection is successful it will then try to download the artifact. The client loop over the Getters list until the download is successful.

This doesn't change the behavior of the existing Getters and improves the code. Multiple Getters can be created as good candidates to download the same source string but using different possibilities, whenever this is necessary, such as the SmbClientGetter and the SmbMountGetter, also implemented in this PR. If there's a new and different approach to retrieve an artifact and you still want to fall back to the current Getter. This allows us to add it as a new Getter without affecting the existing one.

SMB Getters

This PRs adds a SmbClientGetter and a SmbMountGetter to download files from shared folders using SMB protocol.

This PR also adds the necessary config for running the tests. This includes:

  • A new step to the CircleCi that starts two containers, one for the smb server and the other for the go-getter (client), and run the tests inside the go-getter container;
  • Dockerfile and docker-compose files to configure both containers and add shared folders with mock files and directories used on go_smb_test.go and client_test.go;
  • Makefile to help running the containers and tests locally;
  • Readme information about the tests and the SMB protocol.

This is motivated by issues hashicorp/packer#8729 and hashicorp/packer#8552 caused by
hashicorp/packer#7627

// When the ssh: protocol is used explicitly, we recognize it as
// URL form rather than SCP-like form, so the part after the colon
// is a port number, not part of the path.
"git::ssh://git@git.example.com:2222/hashicorp/foo.git",
Copy link
Author

Choose a reason for hiding this comment

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

This test was moved to get_git_test.go

client.go Outdated Show resolved Hide resolved
client.go Outdated Show resolved Hide resolved
client.go Outdated Show resolved Hide resolved
s3/get_s3.go Outdated Show resolved Hide resolved
// is nil, then the default Getters variable will be used.
Getters map[string]Getter
Getters []Getter
Copy link
Contributor

Choose a reason for hiding this comment

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

nice

Comment on lines -61 to -66

// Make sure that we don't start with "/" since we add that below.
if path[0] == '/' {
path = path[1:]
}
return fmt.Sprintf("file:///%s", path)
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this causing a bug ? What makes this change possible ?

Copy link
Author

Choose a reason for hiding this comment

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

This was only for telling the client that the FileDetector detected the source string as valid. In the previous code, once this is back to the client, the client was going to remove the forced "file" to use as a key to look for the getter on the map. No longer necessary.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh right ! 💯 thanks for explaining !

request.go Outdated Show resolved Hide resolved
},
{
"www.googleapis.com/storage/v1/foo/bar.baz",
"gcs::https://www.googleapis.com/storage/v1/foo/bar.baz",
"https://www.googleapis.com/storage/v1/foo/bar.baz",
Copy link
Contributor

Choose a reason for hiding this comment

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

Will a gcs:: get still work ?

Copy link
Author

Choose a reason for hiding this comment

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

Yes. This is the same situation as the FileDetector you asked above. This was for the client.go to know which getter to use.

get_smb_mount.go Outdated Show resolved Hide resolved
get_smb_mount.go Outdated Show resolved Hide resolved
@azr
Copy link
Contributor

azr commented Jun 2, 2020

Nice, this is such a big PR 🙂 ! I tried looking at everything with a bit more attention to the smb code and nice !

@sylviamoss sylviamoss force-pushed the getters_refactoring branch from 6bcaa35 to 0872741 Compare June 2, 2020 14:54
client.go Outdated
@@ -39,6 +35,17 @@ type GetResult struct {
Dst string
}

type getError struct {
// when fatal is true it means that something when wrong with
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be good to have this comment added to any exported method that returns a getError so that it is clear what to expect from the error. Or maybe just export this type as in GetError and add the comment above the type so that it is available via godoc. What do you think?

Copy link
Author

Choose a reason for hiding this comment

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

Right now this one is only returned by the get method which is not exported. Do you think exporting getError is necessary anyways?
I'm updating the comment to make it clear that is used by get.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh in that case you can disregard my comment. I don't think exporting it is necessary if its only used by unexported methods.

Copy link
Contributor

@nywilken nywilken left a comment

Choose a reason for hiding this comment

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

This looks good to me. Nice work. I left one comment around the documentation for the getError type.

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.

3 participants