Goes incorrectly toward api.github.com on Github Enterprise after upgrading to v7

[gustavkj]

Describe the bug After upgrading to v7 requests in workflows on Github Enterprise are sent to api.github.com instead of using the GITHUB_API_URL environment variable.

Seems like that https://github.com/actions/github-script/pull/429 broke the default behavior of @actions/github:

https://github.com/actions/toolkit/blob/20f826bfe76164099ab2403d9ea8509e16843223/packages/github/src/internal/utils.ts#L42-L44

export function getApiBaseUrl(): string {
  return process.env['GITHUB_API_URL'] || 'https://api.github.com'
}

To Reproduce Steps to reproduce the behavior:

1. On Github Enterprise run:

   - uses: actions/github-script@v6
     with:
       github-token: ${{ secrets.GITHUB_TOKEN }}
       script: |
         const { data: pr } = await github.rest.issues.get({
         issue_number: context.issue.number,
           owner: context.repo.owner,
           repo: context.repo.repo
         });

2. It should work
3. Upgrade to v7, but run the same thing:

   - uses: actions/github-script@v7
     with:
       github-token: ${{ secrets.GITHUB_TOKEN }}
       script: |
         const { data: pr } = await github.rest.issues.get({
         issue_number: context.issue.number,
           owner: context.repo.owner,
           repo: context.repo.repo
         });

4. It will fail due to sending request to api.github.com:

   equestError [HttpError]: Not Found
   at /opt/actions-runner/_work/_actions/actions/github-script/e69ef5462fd455e02edcaf4dd7708eda96b9eda0/dist/index.js:9537:21
   at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
   at async eval (eval at callAsyncFunction (/opt/actions-runner/_work/_actions/actions/github-script/e69ef5462fd455e02edcaf4dd7708eda96b9eda0/dist/index.js:35424:16), <anonymous>:4:22)
   at async main (/opt/actions-runner/_work/_actions/actions/github-script/e69ef5462fd455e02edcaf4dd7708eda96b9eda0/dist/index.js:35518:20) {
   status: 404,
   response: {
   url: 'https://api.github.com/repos/org/repo/issues/194',
   status: 404,
   headers: {
     'access-control-allow-origin': '*',
     'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset',
     'content-encoding': 'gzip',
     'content-security-policy': "default-src 'none'",
     'content-type': 'application/json; charset=utf-8',
     date: 'Thu, 16 Nov 2023 11:14:15 GMT',
     'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
     server: 'GitHub.com',
     'transfer-encoding': 'chunked',
     vary: 'Accept-Encoding, Accept, X-Requested-With',
     'x-accepted-oauth-scopes': 'repo',
     'x-content-type-options': 'nosniff',
     'x-frame-options': 'deny',
     'x-github-api-version-selected': '2022-11-28',
     'x-github-media-type': 'github.v3; format=json',
     'x-github-request-id': '1682:BD33:17EF531:183D562:6555F973',
     'x-oauth-scopes': '',
     'x-ratelimit-limit': '5000',
     'x-ratelimit-remaining': '4224',
     'x-ratelimit-reset': '1700134314',
     'x-ratelimit-resource': 'core',
     'x-ratelimit-used': '776',
     'x-xss-protection': '0'
   },
   data: {
     message: 'Not Found',
     documentation_url: 'https://docs.github.com/rest/issues/issues#get-an-issue'
   }
   },
   request: {
   method: 'GET',
   url: 'https://api.github.com/repos/org/repo/issues/194',
   headers: {
     accept: 'application/vnd.github.v3+json',
     'user-agent': 'actions/github-script octokit-core.js/5.0.1 Node.js/20.8.1 (linux; x64)',
     authorization: 'token [REDACTED]'
   },
   request: {
     agent: [Agent],
     fetch: [Function: proxyFetch],
     hook: [Function: bound bound register]
   }
   }
   }

Expected behavior It should still use the GITHUB_API_URL environment variable, and not require extra configuration to work on Github Enterprise

[joshmgross]

I reproduced this issue in #437 - as far as I can tell #429 isn't what broke this as I was able to reproduce the issue with base-url fully removed - https://github.com/actions/github-script/pull/437/commits/98dabfb42fa1f4bcaf07ebc5f0d1bb8d743a0486

I suspect something might have broken upstream in @actions/github or Octokit when they were updated in #425.

[gustavkj]

The plot thickens. Just to try something else, if base-url was to default to ${{ github.api_url }} (or ${{ env.GITHUB_API_URL }}) does it work again then?

[joshmgross]

The plot thickens. Just to try something else, if base-url was to default to ${{ github.api_url }} (or ${{ env.GITHUB_API_URL }}) does it work again then?

That doesn't work either, though it's possible my integration test is flawed.

[gustavkj]

I tried out my thesis on the Github Enterprise Server instance now, it worked! So, it seems that defaulting base-url to ${{ github.api_url }} should work. 🤔

- uses: actions/github-script@v7
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    base-url: ${{ github.api_url }}
    script: |
      const { data: pr } = await github.rest.issues.get({
      issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo
      });

[joshmgross]

@gustavkj could you see if this works on your GHES instance?

- uses: actions/github-script@joshmgross/fix-base-url
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    script: |
      const { data: pr } = await github.rest.issues.get({
      issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo
      });

That's the branch from https://github.com/actions/github-script/pull/437

[gustavkj]

could you see if this works on your GHES instance?

I don't have the latest commit (the GHES instance synced the actions from Github.com last night, so the last commit is 85717e4e3b7e735dc65aff3d600d5a740976d639), it went green but it has other changes.

I tried also also going back and ran pinned to commit sha 28e431842a5f80e8b5f22c48445cb63472acd898, which I think is the same as the latest commit. And it worked as well!

Given that there is a way to force the workflow to go towards the action on Github.com instead of the one synced to the GHES instance, I can give that a try. But I'm not aware of any workaround. Do you know?

Otherwise, as I said, I think 28e431842a5f80e8b5f22c48445cb63472acd898 is the same as the latest commit, right?

[joshmgross]

28e431842a5f80e8b5f22c48445cb63472acd898 is the same, that's right. Thanks for verifying it works, looks like my integration test doesn't actually cover this case.

But I'm not aware of any workaround. Do you know?

Not if you have a local version of the same action, no.

[joshmgross]

Should be fixed in https://github.com/actions/github-script/releases/tag/v7.0.1 and v7 has been updated to match that tag.

[gustavkj]

Thank you for fixing it so fast! I'll try it out when I'm back at work on Monday. Thanks again! 🌟

[gustavkj]

Hi again! I can confirm that it works now. 🌟 Thanks once more!