"Unable to resolve action" 404 error for third-party actions when use-enterprise enabled

[grahamb]

Describe the bug The extension marks a uses: line as an "Unable to resolve action" error when the Use-enterprise setting is enabled.

To Reproduce Steps to reproduce the behaviour:

1. Log into a GitHub Enterprise server in VSCode.
2. Create a workflow that uses a third-party action hosted on github.com, for example:

name: test workflow
on:
  workflow_dispatch:
jobs:
  docker-login:
    - name: Log into docker registry
      uses: docker/login-action@v3
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

Expected behaviour There should be no errors displayed by the vscode-github-actions extension in the workflow file.

Actual behaviour

• An error is displayed on the uses line: "Unable to resolve action docker/login-action@v3, repository or version not found.
• An error is displayed in the GitHub Actions Language Server output: [Error - 1:45:06 PM] Failed to fetch action metadata for docker/login-action/v3: 'Not Found'

Screenshots

Extension Version v0.26.2

Additional context This is likely because the docker/login-action@v3 is not physically present on our GitHub Enterprise Server. GHES has a feature called GitHub Connect, which allows "access to additional features and workflows that rely on the power of GitHub.com". This includes the ability for a GHES instance to fetch third-party workflow actions from github.com – e.g. my GHES installation will see that there is no repository at docker/login-action and attempt to fetch it from https://github.com/docker/login-action.

Suggested fix When the extension encounters a 404 for a uses: action, and if use-enterprise is enabled, the extension should check for the action on github.com. This could, of course, lead to a false-negative if one's GHES did not have GitHub Connect enabled, and did not have the target action on the local GHES. Perhaps a setting along the lines of github-actions.enterprise-github-connect-enabled: true|false could control this behaviour; if true, it would check against github.com after a 404 from GHES.