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

Fix #3032: Remove query parameters in ADD command when the destinatio… #3053

Merged
merged 3 commits into from Mar 22, 2024

Conversation

prima101112
Copy link
Contributor

@prima101112 prima101112 commented Mar 7, 2024

Fixes #3032

problem

ADD https://something?asd dir/ filename returned something?asd

expected : and fixed

the filename should be something

Description

fix filename.Base still returning query params

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

  • Includes unit tests
  • [ ] Adds integration tests if needed.

Reviewer Notes

  • The code flow looks good.
  • Unit tests and or integration tests added.

Release Notes

Describe any changes here so maintainer can include it in the release notes, or delete this block.

Examples of user facing changes:
- fix #3032 

@prima101112
Copy link
Contributor Author

@JeromeJu is this enough? or should i open new PR?

@prima101112
Copy link
Contributor Author

@JeromeJu sorry there was error linter fixed that the test should passed

// ExtractFilename extracts the filename from a URL without its query url
func extractFilename(rawURL string) string {
// not necessarily return an error, due to parsing ambiguities https://pkg.go.dev/net/url#Parse
parsedURL, _ := url.Parse(rawURL)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I see the comment above but can you explain why we don't surface or bubble up this error? From the url.Parse docs

// The url may be relative (a path, without a host) or absolute
// (starting with a scheme). Trying to parse a hostname and path
// without a scheme is invalid but may not necessarily return an
// error, due to parsing ambiguities.

I believe we should bubble up this error, let me know if that makes sense or there is some issue that occurs when doing this from common use cases. I believe the COPY command value when in this method URLDestinationFilepath should have a scheme so we should respect the error

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @aaron-prindle

Thanks, I thought that the filepath example.com/thefile.txt would return an error since it doesn't have the scheme, but it actually doesn't. Thanks for the comment. I've already fixed it and switched the execution order, with ResolveEnvironmentReplacement being executed before extractFilename, i think thats better to replace the env first.

already rebased also
kindly check

@aaron-prindle
Copy link
Collaborator

Thanks for the PR @prima101112! Left one comment related to bubbling up the err from url.Parse

Copy link
Collaborator

@aaron-prindle aaron-prindle left a comment

Choose a reason for hiding this comment

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

LGTm, thanks for the PR @prima101112!

@aaron-prindle aaron-prindle merged commit 02f488a into GoogleContainerTools:main Mar 22, 2024
10 checks passed
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.

ADD using an url with GET parameters and a directory destination includes the GET parameters in the file name
2 participants