@actions/github v3 using Octokit/core

[thboop]

@actions/github is stuck on an older major version of @octokit/rest due to the way we extended the class. Let's move away from extending the Octokit class so we don't encounter this again, and move towards the plugin/defaults model all the JS libraries have been using.

This allows us to customize the octokit is a variety of ways, and reuse existing plugins easily.
In particular, we currently were using @octokit/rest which is just @octokit/core with 3 plugins layered on top:

• @octokit/plugin-paginate-rest - provides the paginate function to paginate rest calls
• @octokit/plugin-rest-endpoint-methods - provides the bulk of the rest apis accessible via functions
• @octokit/plugin-request-log - provides additional logging for rest calls

We don't really need the latter, so we can use @octokit/core to set up a custom octokit with the paginate and rest endpoint plugins and set sane defaults using environmental variables to automatically handle proxy and GHES url scenarios.

We can also choose to implement our own custom plugins as needed going forward, or reuse some of the existing plugins, like GHES api plugins

Why don't we just keep using @octokit/rest?
The core library is really intended to be used if you are extending the plugin model. Type information does not carry well over multiple exports when using plugins, and this offers far more flexibility (at the cost of having to update more packages)

Resolves #468 , #402

[thboop]

We now load proxy settings when the module is imported because of the way defaults works. This required a new test suite for proxy tests.

[ericsciple]

Should we provide a factory method, to help users mock. Might buy us flexibility also (abstraction) instead of inheriting.

For example:

export function createOctokit(token: string, opts?: OctokitOptions): Octokit {
}

Would the types get exported correctly?

Would we need to overload to enable custom list of plugins?

[thboop]

Should we provide a factory method, to help users mock. Might buy us flexibility also (abstraction) instead of inheriting.

For example:

export function createOctokit(token: string, opts?: OctokitOptions): Octokit {
}

Would the types get exported correctly?

Would we need to overload to enable custom list of plugins?

I exported a helper function called getOptions(token: string, opts?: OctokitOptions) which supports this scenario nicely.However, it is a little verbose as you have to pass the output of that function into the constructor like

import {getOptions, GitHub} from `@actions/github`
import {getInput} from `@actions/core`
const token = getInput("token")

const octokit = new GitHub(getOptions(token))

// or pass in octokit options as well
const octokit = new GitHub(getOptions(token{ timeZone: "America/Los_Angeles"}))

// you may also choose to just format your octokit options correctly
const octokit = new github.GitHub({auth: `token ${myToken}`});

But getOptions also allows for people to expand on our Instance as needed.

import {getOptions, GitHub} from `@actions/github`
import {getInput} from `@actions/core`
import {myPlugin} from `my-custom-plugin`
const myGitHub = GitHub.plugin(myPlugin)

const token = getInput("token")
const octokit = new myGitHub(getOptions(token), {//whatever octokit options you want})
// use your new octokit with your plugins, or a community plugin

[ericsciple]

Curious whether there is a big impact to overall size on disk?

[thboop]

There shouldn't be, @octokit/rest imported all 3 of these modules. i'll check but it should be less