feat!: add getOctokit to script context, upgrade @actions/github v9, @octokit/core v7, and related packages

[salmanmkc]

What this does

Upgrades @actions/github to v9 (and related Octokit packages) and adds getOctokit to the script context.

Today, if you need a second Octokit client with a different token (GitHub App, PAT, cross-org), you do something like:

const { getOctokit } = require('@actions/github')
const appClient = getOctokit(process.env.APP_TOKEN)

That breaks in v9 because @actions/github is now ESM-only — require() no longer works. This PR replaces that pattern with a built-in getOctokit that's available directly in the script context, no imports needed:

- uses: actions/github-script@v9
  env:
    APP_TOKEN: ${{ secrets.MY_APP_TOKEN }}
  with:
    script: |
      // primary client uses GITHUB_TOKEN as usual
      await github.rest.issues.addLabels({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        labels: ['needs-review']
      })

      // secondary client uses a different token
      const appOctokit = getOctokit(process.env.APP_TOKEN)
      await appOctokit.rest.repos.createDispatchEvent({
        owner: 'my-org', repo: 'deploy', event_type: 'go'
      })

Works for GHES too:

const ghes = getOctokit(process.env.GHES_TOKEN, {
  baseUrl: 'https://github.example.com/api/v3'
})

The secondary client inherits retry settings, user-agent, proxy config, and plugins from the action — so it behaves consistently with the primary github client. request and retry options are deep-merged (so you can tweak one field without losing the rest), while other options like baseUrl or userAgent replace the default outright if you set them.

Dependency upgrades

Package	Old	New
@actions/github	^6.0.0	^9.0.0
@octokit/core	^5.0.1	^7.0.0
@octokit/plugin-request-log	^4.0.0	^6.0.0
@octokit/plugin-retry	^6.0.1	^8.0.0
Package version	7.0.1	9.0.0

Also updated tsconfig.json to ES2022 with bundler module resolution, and added Jest tsconfig overrides for CJS test compatibility.

Why v9

@actions/github v6 → v9 brings updated Octokit types and the orchestration ID user-agent feature (toolkit#2364). The main breaking change is that require('@actions/github') stops working inside scripts — workflows like MetaMask's that use this pattern will need to switch to the injected getOctokit instead.

Other breaking changes:

• const getOctokit = ... or let getOctokit = ... in scripts will SyntaxError (same as const github = ... today — function parameters can't be redeclared with const/let). Use it directly or use var if you really need to redeclare.
• Internal @actions/github imports (like @actions/github/lib/utils) may have changed paths.

What's in the diff

New:

• src/create-configured-getoctokit.ts — factory wrapper (deep merge, undefined stripping, plugin dedup)
• Tests: 16 factory unit tests, 4 integration tests, CI workflow job with real API calls

Changed:

• src/main.ts — wires factory into script context
• src/async-function.ts — v9 type imports, getOctokit in argument types
• src/retry-options.ts — updated import path for v9
• tsconfig.json — ES2022 + bundler resolution
• package.json — version 9.0.0, dependency bumps
• .github/workflows/integration.yml — new getOctokit test job, user-agent test fix
• README.md — v9 docs, getOctokit section with examples, breaking changes
• .licenses/ — refreshed for all upgraded packages

Testing

• 35 tests across 4 suites, all green
• 15/15 CI checks passing
• Live demo — real multi-token workflow reading a private repo via SECOND_PAT, GraphQL queries, cross-identity verification

---

Note: This PR also includes release prep (version bump to 9.0.0, README examples updated to @v9, V9 breaking changes section, license cache refresh). This can be split into a separate PR if preferred.

Part of https://github.com/github/c2c-actions/issues/10001
Also closes: #707

[github-actions]

Hello from actions/github-script! (fe5245d)

[Copilot]

Pull request overview

This PR exposes getOctokit in the github-script runtime context so user scripts can create additional authenticated Octokit clients (e.g., for multi-token workflows) without relying on require('@actions/github').

Changes:

• Passes getOctokit into the script execution context in src/main.ts.
• Extends the AsyncFunctionArguments TypeScript type to include getOctokit with an Octokit-typed signature.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/main.ts	Adds getOctokit to the object passed into callAsyncFunction so scripts can access it.
src/async-function.ts	Updates the script context type (AsyncFunctionArguments) to type getOctokit and imports Octokit types.

Comments suppressed due to low confidence (2)

src/main.ts:71

• getOctokit is being passed through directly from @actions/github, so any Octokit clients created inside the user script won’t automatically inherit this action’s configured defaults (e.g., base-url for GHES, user-agent with orchestration ID, retries/request options, and the installed retry/requestLog plugins). This can lead to surprising differences between github and getOctokit(...) behavior. Consider exposing a wrapper that pre-applies the same options/plugins by default (while still allowing callers to override/extend options/plugins when needed).

      github,
      octokit: github,
      getOctokit,
      context,
      core,

src/async-function.ts:20

• This adds a new deep import from @octokit/core/types, but the codebase already imports Octokit types via @octokit/core/dist-types/types (e.g. src/retry-options.ts). To stay consistent (and to reduce the risk of relying on a non-exported subpath), align the import path with the existing convention or derive the type directly from @actions/github (e.g., type getOctokit as typeof import('@actions/github').getOctokit) so the signature can’t drift from the actual implementation.

import {GitHub} from '@actions/github/lib/utils'
import * as glob from '@actions/glob'
import * as io from '@actions/io'
import type {OctokitOptions, OctokitPlugin} from '@octokit/core/types'

const AsyncFunction = Object.getPrototypeOf(async () => null).constructor

export declare type AsyncFunctionArguments = {
  context: Context
  core: typeof core
  github: InstanceType<typeof GitHub>
  octokit: InstanceType<typeof GitHub>
  getOctokit: (
    token: string,
    options?: OctokitOptions,
    ...additionalPlugins: OctokitPlugin[]
  ) => InstanceType<typeof GitHub>

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mnocentelli1968-gif]

Viewed