github-script Compatibility

actions/github-script Compatibility

actions/github-script works broadly on the Forgejo proxy stack. Out of 11 tested usage patterns, 10 pass across both v7 and v9 of the action. The single failing case is GraphQL — a known Forgejo platform limitation, not a proxy-specific issue.

These results come from an automated compatibility testbed that runs against the live proxy and publishes machine-readable reports for each run. See How to check compatibility below for links.

Overview

pie title actions/github-script compatibility (run 2, 10/11 cases)
    "Compatible ✅" : 10
    "Incompatible ❌" : 1

The proxy correctly forwards all standard REST API calls. The four preflight probes — routing, repo-transport (repo), repo-git-transport (repo.git), and the API probe — all succeed, confirming that the proxy transport layer is healthy from the runner’s perspective.

Compatibility Matrix

Case ID	Description	Compatible
v7_default	actions/github-script@v7 with the default Forgejo API wiring	✅
v7_explicit	actions/github-script@v7 with explicit base-url	✅
v9_default_implicit_token	actions/github-script@v9 without an explicit github-token input	✅
v9_explicit	actions/github-script@v9 with explicit base-url	✅
v9_separate_file	Script loaded from a repository file via require(...)	✅
v9_separate_async_file	Async helper loaded from a repository file	✅
v9_npm_require	Installed npm package accessed from inside the script runtime	✅
v9_esm_import	Absolute-path ESM import from the checked-out workspace	✅
v9_get_octokit	Additional Octokit client created with getOctokit(...)	✅
v9_exec	@actions/exec used from inside the github-script runtime	✅
v9_graphql	GraphQL query via github.graphql(...)	❌

Passing Cases

Each of the 10 compatible cases exercises a different usage pattern documented in the upstream actions/github-script README or commonly found in the wild.

v7_default and v7_explicit confirm that the older v7 release of github-script works unchanged. Both the implicit base-URL wiring (read from the GITHUB_API_URL environment variable) and an explicit base-url: input succeed. This matters because many workflows pin to @v7 for stability.

v9_default_implicit_token verifies the most common v9 pattern: no github-token: input, relying on the built-in ${{ github.token }}. The action correctly resolves the token and the proxy correctly routes the resulting API calls.

v9_explicit mirrors the same case but with an explicit base-url: input, confirming both token strategies work at v9.

v9_separate_file and v9_separate_async_file test the README pattern where the script body is kept in a separate repository file and loaded at runtime via require(...). Both synchronous and async variants pass, meaning teams can organise their workflow scripts as normal Node.js modules.

v9_npm_require exercises the case where package.json lists a runtime dependency and the script require()s it. The action installs packages before running the script, and the npm registry access works correctly on the proxy stack.

v9_esm_import uses an absolute-path ESM import(...) call from the workspace root. This covers the newer module style and confirms the script runtime handles ES modules.

v9_get_octokit tests github.getOctokit(github.token, { baseUrl }) — a pattern used when you want a second, independently-configured Octokit client inside the same script step. The additional client is wired to the proxy correctly.

v9_exec uses @actions/exec (the sibling toolkit package) from within a github-script step. The package is available in the runner environment and exits with code 0.

Known Limitation: GraphQL

The v9_graphql case fails with a non-success script_outcome. When a step calls github.graphql(...), github-script issues a POST /graphql request. The Forgejo REST API does not expose a GraphQL endpoint; the proxy returns 501 Not Implemented (or 405 Method Not Allowed) for that path.

This is a Forgejo platform limitation, not a proxy-stack regression. GitHub’s GraphQL API (api.github.com/graphql) has no equivalent in Forgejo. Any workflow that uses github.graphql(...) will fail on any Forgejo instance, regardless of whether the proxy is present.

flowchart LR
    step["github-script step\ngithub.graphql(...)"]
    proxy["forgejo-proxy\nPOST /graphql"]
    forgejo["Forgejo\n(no GraphQL endpoint)"]
    result["❌ 501 Not Implemented"]

    step --> proxy --> forgejo --> result

Workaround: Replace github.graphql(...) calls with equivalent REST API calls. Most data accessible via GraphQL on GitHub (repository metadata, issues, pull requests, users) is also available through Forgejo’s REST endpoints. See the Forgejo API docs for the available REST surface.

The issue tracking full GraphQL support is forgejo-proxy#7.

Preflight Health

Each test run also validates the four proxy transport probes before running any case:

Probe	Description	Run 2 result
route	Basic routing through the proxy layer	✅
transport_repo	Action URL shape repo resolves correctly	✅
transport_repo_git	Action URL shape repo.git resolves correctly	✅
api_probe	REST API accessible with ${{ github.token }}	✅

All four probes pass, meaning proxy transport is healthy and issues are always case-specific rather than infrastructure-wide.

How to Check Compatibility

The compatibility testbed runs automatically on push and publishes human-readable and machine-readable reports to the compat-results branch of the testbed repository.

• Testbed repository: forgejo-proxy/forgejo-proxy-compatibility-test-of-github-script
• Latest Markdown report: compat-results/latest.md
• Latest JSON report: compat-results/latest.json

Run-numbered archives (e.g., run-2.md, run-2.json) are retained alongside latest.* for historical comparison across infrastructure changes.