feat!: expose getOctokit in script context and upgrade to @actions/github v9#700
Open
feat!: expose getOctokit in script context and upgrade to @actions/github v9#700
Conversation
|
Hello from actions/github-script! (9206a2b) |
There was a problem hiding this comment.
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
getOctokitinto the script execution context insrc/main.ts. - Extends the
AsyncFunctionArgumentsTypeScript type to includegetOctokitwith 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
getOctokitis 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-urlfor GHES,user-agentwith orchestration ID,retries/request options, and the installedretry/requestLogplugins). This can lead to surprising differences betweengithubandgetOctokit(...)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., typegetOctokitastypeof 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.
pelikhan
approved these changes
Mar 9, 2026
- @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 - Update tsconfig.json to use moduleResolution: "bundler" for ESM exports map support - Update import paths for new package structures - Update build:types script for compatible compiler options Co-authored-by: angel-jiakou <115738347+angel-jiakou@users.noreply.github.com> Agent-Logs-Url: https://github.com/actions/github-script/sessions/17de5ca1-8bdc-41e4-a06d-ab2d8c2e6e8c
c7fb361 to
2fe016f
Compare
Verifies the real getOctokit from @actions/github creates functional Octokit clients when invoked through callAsyncFunction, ensuring: - Secondary clients have full REST/GraphQL API surface - Secondary clients are independent from primary github client - GHES base URL option is accepted - Multiple tokens produce distinct client instances
1bdc919 to
7f52c47
Compare
…it name
Replace function-parameter injection with const destructuring + block scope
so that user scripts can shadow injected names (e.g. const { getOctokit } = ...)
without SyntaxError. This eliminates the need for the createOctokit rename and
aligns with the ADR's getOctokit naming.
Changes:
- callAsyncFunction now wraps user source in a block: const {...} = __scope__; { source }
- Renamed createOctokit binding back to getOctokit everywhere
- Added 5 new tests: const/let shadowing, await, return, syntax error, access
- Updated integration workflow and type declarations
createOctokit to script context for multi-token workflows…ards - Change const to var destructuring in callAsyncFunction so var redeclaration and reassignment of injected names still works (v8 compat) - Add identifier validation for argument keys (defensive for exported API) - Add __scope__ collision guard - Fix integration test hardcoded repo name to use github.repository - Add 4 new tests: var redecl, reassignment, invalid key, __scope__ guard
Remove block-scope var destructuring mechanism — use original function-parameter injection (new AsyncFunction(...keys, source)) to minimize risk. getOctokit is added as a standard function parameter alongside github, core, context, etc. The const/let redeclaration collision is accepted as a documented trade-off in the major version bump.
d2bb7e5 to
e9d46e1
Compare
…otes - Expand V9 breaking changes section with new features and breaking changes - Add orchestration ID user-agent as new feature - Document const/let redeclaration SyntaxError for getOctokit binding - Add note callout in getOctokit docs section about injected parameter
require('@actions/github') no longer works in v9 scripts because
@actions/github v9 is ESM-only. Users who previously used this
pattern (e.g. MetaMask) should use the injected getOctokit instead.
Apply stripUndefined to defaultOptions too, not just user options. Prevents log: undefined and previews: undefined from main.ts opts from being passed through to the Octokit constructor where they could interfere with Octokit's own defaults.
The error message referenced $expected but the variable was never set, making failure diagnostics unhelpful.
- Deep-copy retry and request when passing opts to factory to prevent shared references with the primary client - Document that request/retry are deep-merged while other options are replaced outright
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Upgrades
@actions/githubto v9 and addsgetOctokitto the script context.Today, if you need a second Octokit client with a different token (GitHub App, PAT, cross-org), you do something like:
That breaks in v9 because
@actions/githubis now ESM-only —require()no longer works. This PR replaces that pattern with a built-ingetOctokitthat's available directly in the script context, no imports needed:Works for GHES too:
The secondary client inherits retry settings, user-agent, proxy config, and plugins from the action — so it behaves consistently with the primary
githubclient.requestandretryoptions are deep-merged (so you can tweak one field without losing the rest), while other options likebaseUrloruserAgentreplace the default outright if you set them.Why v9
@actions/githubv6 → v9 brings updated Octokit types and the orchestration ID user-agent feature (toolkit#2364). The main breaking change is thatrequire('@actions/github')stops working inside scripts — workflows like MetaMask's that use this pattern will need to switch to the injectedgetOctokitinstead.Other breaking changes:
const getOctokit = ...orlet getOctokit = ...in scripts will SyntaxError (same asconst github = ...today — function parameters can't be redeclared with const/let). Use it directly or usevarif you really need to redeclare.@actions/githubimports (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)Changed:
src/main.ts— wires factory into script contextsrc/async-function.ts— v9 type imports,getOctokitin argument typespackage.json— version 9.0.0, dependency bumpstsconfig.json— ES2022 + bundler resolutionREADME.md— v9 docs, getOctokit section with examples, breaking changes.github/workflows/integration.yml— new getOctokit test job, user-agent test fixTesting