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

Escape branch string before inserting it in URL #2948

Merged
merged 1 commit into from
Oct 4, 2023
Merged

Conversation

k0ral
Copy link
Contributor

@k0ral k0ral commented Oct 3, 2023

When a branch name with special characters like % is passed to the RepositoryService.GetBranch() method as is, an error is currently returned:

invalid URL escape "%"

Passing an escaped branch name to RepositoriesService.GetBranch() works fine.

Here's a minimal reproducer

import (
	"context"
	"net/http"
	"testing"

	"github.com/google/go-github/v53/github"
	"github.com/stretchr/testify/require"
)

func TestGetBranch(t *testing.T) {
	t.Parallel()
	ctx := context.Background()

	githubClient := github.NewClient(&http.Client{
		Transport: http.DefaultTransport,
	})
	owner := "samstickkz"
	project := "curr"
	branchName := "Feature/authentication_90%"
	branch, response, err := githubClient.Repositories.GetBranch(ctx, owner, project, branchName, false)

	require.Nil(t, err)
	t.Logf("Response: %+v", response)
	t.Logf("Branch: %+v", branch)
}

This sounds like a bug to me, as I believe users of that method shouldn't be expected to escape the branch name before calling it, as this is a private implementation quirk that they shouldn't be aware of. This PR patches all branch-related methods to automatically escape the branch name in the endpoint URL.

There's actually a precedent for ref parameter, and I suspect that other variables are prone to the same issue. I am conservatively patching only the branch variable, as this is the only one I have tested thoroughly. Note that, contrary to ref use case, my tests suggest that it's okay to escape / characters for branch names.

⚠️ Breaking change: for users that currently bypass this issue by feeding escaped strings to RepositoryService.GetBranch() method (and other branch-related methods), this change will be breaking.

@codecov
Copy link

codecov bot commented Oct 3, 2023

Codecov Report

Merging #2948 (f77ef83) into master (5224e34) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #2948   +/-   ##
=======================================
  Coverage   98.17%   98.17%           
=======================================
  Files         145      145           
  Lines       12735    12735           
=======================================
  Hits        12502    12502           
  Misses        158      158           
  Partials       75       75           
Files Coverage Δ
github/repos.go 98.89% <100.00%> (ø)

@gmlewis gmlewis changed the title fix!: Escape branch string before inserting it in URL Escape branch string before inserting it in URL Oct 3, 2023
@gmlewis gmlewis added NeedsReview PR is awaiting a review before merging. Breaking API Change PR will require a bump to the major version num in next release. Look here to see the change(s). labels Oct 3, 2023
@gmlewis
Copy link
Collaborator

gmlewis commented Oct 3, 2023

Honestly, I'm quite surprised that this issue has never come up before... as this repo is how many years old? 10?!?

However, I think you are right.

I'm wondering if each of the modified endpoints needs a comment in the documentation stating something like:

// Note that the branch name is URL path escaped for you. See: https://pkg.go.dev/net/url#PathEscape

Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

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

Can you please add unit tests that demonstrate this new super power?

@k0ral k0ral force-pushed the escape branch 2 times, most recently from c44f623 to 2423e20 Compare October 4, 2023 08:38
@k0ral
Copy link
Contributor Author

k0ral commented Oct 4, 2023

@gmlewis PR updated with additional comments and unit tests.

@k0ral k0ral requested a review from gmlewis October 4, 2023 09:52
Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

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

Thank you, @k0ral !
LGTM.

Awaiting second LGTM+Approval from any other contributor to this repo before merging.

@gmlewis gmlewis mentioned this pull request Oct 4, 2023
3 tasks
@WillAbides
Copy link
Contributor

I have a bit of concern about this being a subtle breaking change that could take a long time to discover after upgrading. I'm looking at ways to mitigate that. I'll be back to review later today.

Copy link
Contributor

@WillAbides WillAbides left a comment

Choose a reason for hiding this comment

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

I'm still a little hesitant about the breaking change, but after a some pondering I can't come up with anything better that doesn't add unnecessary complexity.

@gmlewis gmlewis removed the NeedsReview PR is awaiting a review before merging. label Oct 4, 2023
@gmlewis
Copy link
Collaborator

gmlewis commented Oct 4, 2023

Thank you, @WillAbides !
Merging.

@gmlewis gmlewis merged commit 5ea85e2 into google:master Oct 4, 2023
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking API Change PR will require a bump to the major version num in next release. Look here to see the change(s).
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants