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

[Resolves #71] Add trimpath arg to gobuild #102

Merged
merged 7 commits into from
Nov 1, 2019
Merged

[Resolves #71] Add trimpath arg to gobuild #102

merged 7 commits into from
Nov 1, 2019

Conversation

stanleynguyen
Copy link
Contributor

I'm not sure about -trimpath behavior with pre-1.13 go versions though.
I'm expecting -trimpath to not do anything for pre-1.13 versions

@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@jonjohnsonjr
Copy link
Collaborator

I'm expecting -trimpath to not do anything for pre-1.13 versions

I think it actually complains if you pass a non-existent flag:

$ go build --foo bar
flag provided but not defined: -foo

You could use build constraints to only add -trimpath for go1.13 and above. This isn't perfect, though. Since we shell out to the go command, someone could have a go binary built with 1.13 but have go 1.12 installed, in which case that would fail. We could shell out to go version and do some string parsing, but I think that's actually worse.

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@stanleynguyen
Copy link
Contributor Author

This makes me wonder if we should include some test cases to cover the actual execution of the ko binary as the current test cases failed to flag trimpath even when tested with go1.12 in Travis

@jonjohnsonjr
Copy link
Collaborator

This makes me wonder if we should include some test cases to cover the actual execution of the ko binary as the current test cases failed to flag trimpath even when tested with go1.12 in Travis

Yeah that would be hugely helpful. We could test ko ko publishing itself to a local docker daemon in travis, which would get you most of the coverage. We could even use something like kind or minikube to ko apply this test and assert that the output is what we expected.

@stanleynguyen
Copy link
Contributor Author

@jonjohnsonjr I will include the test cases that covers what we've just discussed as well 👍

@stanleynguyen
Copy link
Contributor Author

@jonjohnsonjr Added integration test using kind on travis env

@jonjohnsonjr
Copy link
Collaborator

Wow this is really awesome, thanks! Much better than I would have done myself 😄

@jonjohnsonjr jonjohnsonjr merged commit be4e1ff into ko-build:master Nov 1, 2019
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