Introduces custom GitHub configuration

[satorg]

Fixes #379

Adds an implicit config parameter to Github instance which allows to override the default configuration by injecting a custom implicit GithubConfig instance into a current scope:

val client: Client[IO] = ???
val accessToken: String = ???
implicit val myConfig = GithubConfig(baseUrl = "https://<whatever>/api/v3", ...)

val github = Github[IO](client, Some(accessToken)) // `myConfig` will be picked up while in the scope

[satorg]

Some questions and concerns I have got:

• I passed config: GithubConfig as an implicit parameters all the way from Github through GithubAPIv3 and down to HttpClient where it is really used. But I am not completely sure it should be implicit everywhere. May be it is reasonable to make it implicit in the Github class only.
• I found out that there's application.conf file in the resources directory with the same configuration defaults as the GithubConfig.default instance has. Is this configuration file used somewhere and shouldn't it be reference.conf instead of application.conf since github4s is supposed to be a library?
• The Github constructor accepts accessToken as a separate parameter, but shouldn't it be a part of the configuration object?

[BenFradet]

The Github constructor accepts accessToken as a separate parameter, but shouldn't it be a part of the configuration object?

No, the access token needs to be modified all the time, the default config will be fine for most people

I found out that there's application.conf file in the resources directory with the same configuration defaults as the GithubConfig.default instance has. Is this configuration file used somewhere and shouldn't it be reference.conf instead of application.conf since github4s is supposed to be a library?

let's remove it, not sure why it's there

I passed config: GithubConfig as an implicit parameters all the way from Github through GithubAPIv3 and down to HttpClient where it is really used. But I am not completely sure it should be implicit everywhere. May be it is reasonable to make it implicit in the Github class only.

I think top-level is enough, no need for implicits internally.

[codecov-io]

Codecov Report

Merging #384 into master will decrease coverage by 0.18%.
The diff coverage is 16.66%.

@@            Coverage Diff             @@
##           master     #384      +/-   ##
==========================================
- Coverage   78.71%   78.53%   -0.19%     
==========================================
  Files          23       24       +1     
  Lines         531      531              
  Branches        2        0       -2     
==========================================
- Hits          418      417       -1     
- Misses        113      114       +1

Impacted Files	Coverage Δ
github4s/src/main/scala/github4s/Github.scala	0% <ø> (ø)	⬆️
...s/src/main/scala/github4s/modules/GithubAPIs.scala	0% <0%> (ø)	⬆️
...ithub4s/src/main/scala/github4s/GithubConfig.scala	0% <0%> (ø)
...ub4s/src/main/scala/github4s/http/HttpClient.scala	11.11% <0%> (-3.18%)	⬇️
...4s/src/main/scala/github4s/http/Http4sSyntax.scala	0% <0%> (ø)	⬆️
.../scala/github4s/interpreters/AuthInterpreter.scala	46.66% <50%> (ø)	⬆️
...cala/github4s/interpreters/IssuesInterpreter.scala	100% <0%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e759408...d9aa475. Read the comment docs.

[satorg]

@BenFradet I have updated the PR according to our conversations, please take a look.
I'm not sure if there's necessity to add some unit tests for these changes, but if you think the tests will be useful here please let me know.

[BenFradet]

LGTM except for a few minor comments 👍

However, I think this change deserves a mention in the documentation, wydt?

[satorg]

@BenFradet,
I fixed PR according to your comments. Also I added some docs in the "Getting Started" section.
Although I'm not completely sure it is an appropriate place for that. Could you take a look please?

[BenFradet]

Looking good 👍

[satorg]

@BenFradet, fixed, please take a look.
If you think that my English is a bit clumsy there then it is probably the case :)
So feel free to suggest a better wording please.

[BenFradet]

Thanks a lot 👍