github / vscode-github-actions

GitHub Actions extension for VS Code
https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-github-actions
MIT License
476 stars 72 forks source link

Unable to find reusable workflow #254

Open hugohjerten opened 11 months ago

hugohjerten commented 11 months ago

Describe the bug When leveraging local reusable workflows, i.e. referencing other workflows inside of the .github/workflows/ directory, the extension claims that it cannot find the reusable workflow. The reusable workflow is indeed in the right place, and it executes successfully by Github Actions.

To Reproduce Steps to reproduce the behavior:

  1. With the following directory structure:

    .github/workflows/
      - base.yml
      - reusable.yml

    And the following workflows:

    # base.yml
    name: base
    on:
    pull_request:
    
    permissions:
    contents: read
    id-token: write
    
    jobs:
    reusable:
      uses: ./.github/workflows/reusable.yml
      with:
        EXAMPEL: example
    # reusable.yml
    name: reusable
    on:
    workflow_call:
      inputs:
        EXAMPLE:
          description: Example.
          type: string
          required: true
    
    permissions:
    contents: read
    id-token: write
    
    jobs:
    reusable:
      name: Example
      runs-on: ubuntu-latest
      steps:
        - name: Example step
          run: echo "${{ inputs.EXAMPLE }}"
  2. Go to base.yml in VS Code.
  3. The linting error Unable to find reusable workflow is presented. In addition, this is the output from Github Actions Language:
    [Error - 09:26:39] Request textDocument/documentLink failed.
    Message: Request textDocument/documentLink failed with message: Invalid file reference: .github/workflows/reusable.yml
    Code: -32603

Expected behavior As this is indeed a valid file reference according to github documentation, and since it does indeed execute successfully, this error should not occur.

Screenshots Screenshot 2023-09-01 at 09 39 51

Extension Version v0.26.1

Kaloszer commented 10 months ago

+1

dotdev-nikolaj commented 9 months ago

Any news? I'm getting this too! :)

andrewakim commented 9 months ago

:wave: Can you try pinning the reusable workflow to a branch or SHA to see if it resolves the error?

kszonek commented 9 months ago

Same here.

Pinning to branch and SHA does not resolve the issue.

Also even if branch is not yet pushed, it should be able to find the file locally (as soon as the branch is published, file will be there and if reusable workflow is triggered on PR, it will be triggered and will pass).

ebrannin-bw commented 9 months ago

This seems to happen to me when I open the .github folder as a Project in VS Code.

I have two windows open right now:

Why would I not open the repo-root instead, you might ask? Because:

  1. This is a Java project, and I don't want VS Code auto-building it just for some GHA tweaks
  2. This project is also open in IntelliJ IDEA, and things get really bad when both IDEs start constantly overwriting each other's build outputs
  3. Looking up in this thread, apparently I'm not alone in this unexpected behavior ;p

I think it would help if this extension could walk up the directory tree and deal with paths relative to the location of the files' closest-parent .github directory.

kszonek commented 9 months ago

I have my root folder opened - and it was happening to me... but now it solved itself, I relaunched VSCode this morning (update) and paths work fine now.

ebrannin-bw commented 9 months ago

I'm glad it's solved for you! I just restarted-to-update too, and it's still not resolving relative paths with .github as workspace root.

ojciec-dev commented 8 months ago

+1 Same here, everything runs fine on GitHub, but locally it shows errors.

I'm using GitHub Actions v0.26.2

VS Code

Version: 1.84.0 (Universal)
Commit: d037ac076cee195194f93ce6fe2bdfe2969cc82d
Date: 2023-11-01T11:30:19.406Z (4 days ago)
Electron: 25.9.2
ElectronBuildId: 24603566
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Darwin arm64 23.1.0
image image

Has anyone found any workaround, while we're waiting for getting it fixed?

Sridharan271 commented 8 months ago

It got solved when you close and open your vs code editor

hitsthings commented 7 months ago

Closing VS Code did not fix it for me. And the only output for the Github Actions plugin is unhelpful: image

Dave-EMIS commented 6 months ago

I had this today after a VS Code Update.

I'm using WSL2 and Dev Containers.

To fix it I closed VS Code again, went to the WSL CLI and ran code . which updates the VS Code Server in WSL, then I reopened the Dev Container and it is working.

Not sure if all these steps are necessary, YMMV.

danstreeter-es commented 5 months ago

Restarting my VSCode many times did not help, however ReLOADING the window did with the command palette "Developer: Reload Window".

Confirmed by changing the name of a valid file to missing (I get the red line) then changing it back the error goes away.

rantoniuk commented 4 months ago

Still happening on MacOS. Reloading window doesn't help, restarting doesn't help. Ref: https://github.com/github/vscode-github-actions/issues/68

Edit, what helped for me was to:

kellervater commented 3 months ago

In my case the error message was truly misleading. I was missing a version declarator like:

uses: <orga>/<repo>/.github/workflows/workflow.yaml@main

When adding @<version> it worked in an instant. A version tag works as well. hth

lure8225 commented 3 months ago

Same problem here and I actually don't want to specify a version as it is in the same repo and shall be used from the same branch es the invoking workflow. Also it should link to the local file in vscode as in my case it is local and in the same repo

lsivolella commented 3 months ago

I had the same issue when I was opening my .yml files on Visual Code as "standalone" files. I fixed this by going to the Explorer tab and opening my whole project in Visual Code. Then it was able to identify the workflows as a composition of files.

lure8225 commented 2 months ago

Yes for me opening the whole folder in code in a new instance seems to have fixed it. I had the folder open from the start but I guess there is some problem with the initialization after install