Hook should contain Config of type HookConfig
himazawa opened this issue · comments
The CreateHook
method
go-github/github/repos_hooks.go
Line 85 in 6ca4d14
currently wants a Hook
parameter that has Config
of type map[string]interface{}
go-github/github/repos_hooks.go
Line 54 in 6ca4d14
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:
go-github/github/orgs_audit_log.go
Lines 24 to 31 in 6ca4d14
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?
On it.
I also noticed that:
https://github.com/google/go-github/blob/master/github/apps_hooks.go#L18
https://github.com/google/go-github/blob/master/github/orgs_hooks_configuration.go#L18
https://github.com/google/go-github/blob/master/github/repos_hooks_configuration.go#L18
and
https://github.com/google/go-github/blob/master/github/apps_hooks.go#L39
https://github.com/google/go-github/blob/master/github/orgs_hooks_configuration.go#L39
https://github.com/google/go-github/blob/master/github/repos_hooks_configuration.go#L39
are basically the same code. Do you want to create two generic function for them?
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.