vscode-github-actions
vscode-github-actions copied to clipboard
"Unable to resolve action" 404 error for third-party actions when use-enterprise enabled
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:
- Log into a GitHub Enterprise server in VSCode.
- 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 actiondocker/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.