google / go-github

Go library for accessing the GitHub v3 API

Home Page:https://pkg.go.dev/github.com/google/go-github/v62/github

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hook should contain Config of type HookConfig

himazawa opened this issue · comments

The CreateHook method

func (s *RepositoriesService) CreateHook(ctx context.Context, owner, repo string, hook *Hook) (*Hook, *Response, error) {

currently wants a Hook parameter that has Config of type map[string]interface{}

Config map[string]interface{} `json:"config,omitempty"`

This forces the user to manually define each config properties.

My proposal is to change the Config to HookConfig, that for some reasons I'm not aware of is defined here:

type HookConfig struct {
ContentType *string `json:"content_type,omitempty"`
InsecureSSL *string `json:"insecure_ssl,omitempty"`
URL *string `json:"url,omitempty"`
// Secret is returned obfuscated by GitHub, but it can be set for outgoing requests.
Secret *string `json:"secret,omitempty"`
}

This could be a breaking change for people currently using the CreateHook function (and every other functions taking Hook as input) so I am asking first how you want to proceed about it.

Hmmm... excellent point. From the official docs, I don't see any reason why we shouldn't switch Config over to *HookConfig and have a breaking API change.

You might also want to provide a godoc comment for the InsecureSSL field since the warnings in the official docs look pretty serious.

Would you like to make a PR, @himazawa, or shall I open this issue up to other contributors?

Do you want to create two generic function for them?

I'm this repo, we have consciously tried to always support the most recent two minor versions of the Go compiler, and now with the release of Go 1.22.0 I think it is now safe to say that Go generics are a welcome addition!

Later tonight I will try to update the maintenance scripts and GitHub Action workflow scripts to support versions 1.21.x and 1.22.x of the Go compiler.
After that gets merged, we should be able to accept PRs with generics.

🎉

Wait, I was not talking about "generic" in that way. There is no need for them in this specific case, but we can use a a common function for all of them.
The real question is: is it ok if we aggregate this 3 functions into one?

Looking now at your six links, no, we will not be aggregating all the functions into one, as that goes against the overall philosophy of this repo. This repo provides methods for each endpoint, and each of those links have different endpoints and/or HTTP methods, so they are all unique and will remain distinct. Thanks for asking.

Sorry for not looking at your links before responding earlier - that was my bad.