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

Add flag to upload coverage insecurely #310

Merged
merged 1 commit into from
Feb 26, 2018

Conversation

toddmazierski
Copy link
Contributor

Add an --insecure flag to both the after-build and upload-coverage sub-commands to upload test coverage insecurely (without HTTPS).

This is not recommended for general use. This is intended for use in private environments where the benefits of secure transfer outweigh the operational costs.

@CLAassistant
Copy link

CLAassistant commented Feb 23, 2018

CLA assistant check
All committers have signed the CLA.

Copy link
Contributor

@ale7714 ale7714 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! But I also pair on it so I think it's worth having some different 👀 .


parsed.Scheme = "http"

return parsed.String()
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we always set the scheme on the parsed url? https normally but if the insecure flag is set, http?

Copy link
Contributor Author

@toddmazierski toddmazierski Feb 23, 2018

Choose a reason for hiding this comment

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

Ah, interesting idea. That would make the code simpler (we could remove the guard clause).

That change might give the impression to readers, though, that the scheme we're receiving from the API is invalid or missing. It's not, really—we're just overriding it in this very specific mode of operation. But, of course, realistically there's only two possibilities: https or http. 😛

I could go either way. 😄 Do you favor one way or the other?

Copy link
Contributor

Choose a reason for hiding this comment

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

I kind of like that regardless of the URL scheme returned via the API, that we would be enforcing secure transport by default and only disabling it if the insecure flag is used.

Up to you though. Fine with whichever you prefer!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I kind of like that regardless of the URL scheme returned via the API, that we would be enforcing secure transport by default and only disabling it if the insecure flag is used.

I dig it! I'll make that change. 👍

Copy link
Contributor

@ale7714 ale7714 left a comment

Choose a reason for hiding this comment

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

After some conversation, I feel pretty good with the PR and how the change is very encapsulated.

parsed, err := url.Parse(rawUrl)

if err != nil {
return rawUrl
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is an unusable value, I guess the reporter will fail further downstream at the http post request?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In case it wasn't obvious, I'm new to Go. So this might not be desirable. 😄 Would you recommend a panic instead?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not familar with all of the error handling in place but it looks like you could do something like this if you wanted to handle the url parsing error directly:

func (u Uploader) TransformPostBatchURL(rawUrl string) (string, errror) {
  parsed, err := url.Parse(rawUrl)

  if err != nil {
    return nil, err
  }
  // snip
}

and change the calling code to:

postBatchURL, err := u.TransformPostBatchURL(batchLinks.Links.PostBatch)

if err != nil {
  return errors.WithStack(err)
}

return u.SendBatches(testReport, postBatchURL)

Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW i thought about this but having an unusable URL it's extremely unlikely and I think this a nice to have but not super necessary. Personally I find super annoying those if 🙈

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, OK!

It's unlikely, @ale7714, but @dblandin's suggestion means it'll be much easier to discover and debug.

Copy link
Contributor

@dblandin dblandin left a comment

Choose a reason for hiding this comment

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

One quick comment/question. LGTM!

Add an `--insecure` flag to both the `after-build` and `upload-coverage`
sub-commands to upload test coverage insecurely (without HTTPS).

This is *not* recommended for general use. This is intended for use in
private environments where the benefits of secure transfer outweigh the
operational costs.
@toddmazierski toddmazierski merged commit 2c088e1 into master Feb 26, 2018
@toddmazierski toddmazierski deleted the todd/256-insecure-upload branch February 26, 2018 16:21
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.

None yet

4 participants