Fix GitHub Actions "No Files Were Found with the Provided Path (2026)

This error means your GitHub Actions workflow tried to upload or download artifacts, but the specified path didn’t contain any files.

Here are the most common reasons this happens and how to fix them:

1. Incorrect Path in artifact or upload-artifact Action:

Diagnosis: Double-check the path parameter in your actions/upload-artifact or actions/download-artifact step. It’s case-sensitive and must exactly match the directory or file pattern where artifacts are generated or expected.
Cause: A typo, incorrect casing, or a misunderstanding of relative paths within the workflow’s execution environment.
Fix (upload-artifact): Ensure the path points to a directory that actually contains files you want to upload. For example, if your build process outputs files to ./build/output, your action should look like this:
```
- name: Upload build artifacts
  uses: actions/upload-artifact@v4
  with:
    name: my-app-build
    path: build/output/
```
Fix (download-artifact): If you’re downloading, ensure the path you’re specifying for download matches the name or path used during upload. If the artifact was uploaded with name: my-app-build, you download it by its name:
```
- name: Download build artifacts
  uses: actions/download-artifact@v4
  with:
    name: my-app-build
    path: ./downloaded_artifacts/ # Optional: specify a directory to download into
```
Why it works: The path parameter is the direct instruction to the action on where to find (upload) or place (download) files. Mismatches here are the most direct cause of "no files found."

2. Artifacts Not Being Generated:

Diagnosis: Before the upload-artifact step, add a simple step to list the contents of the directory you expect to contain artifacts.

- name: List files in expected artifact directory
  run: ls -R ./build/output/
  # Or for Windows:
  # run: dir /s .\build\output\

Cause: The preceding build or compilation step failed silently, produced no output, or put files in a different location than anticipated.
Fix: Debug the step that’s supposed to generate the artifacts. Look at its logs for errors. Ensure its output directory is correctly configured and that it’s actually creating files. If the build command is make, ensure make isn’t exiting with a non-zero status code that you’re ignoring.
Why it works: This confirms whether the files are ever created before the upload action runs. If they aren’t there, the upload action has nothing to upload.

3. Using working-directory Incorrectly:

Diagnosis: If your upload-artifact step is nested within a job step that uses working-directory, the path is relative to that working-directory, not the root of your repository.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run build in a specific directory
        working-directory: ./my-project/
        run: |
          npm install
          npm run build # This creates files in ./my-project/dist/

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: my-app-build
          path: dist/ # This path is relative to ./my-project/

Cause: The path specified in upload-artifact is interpreted relative to the working-directory of the step or the job, not the repository root, unless the path itself is an absolute path (which is rare and usually not recommended).
Fix: Adjust the path to be relative to the working-directory. If your build output is in ./my-project/dist/ and your working-directory is ./my-project/, then the path for upload-artifact should be dist/. If you want to upload files from the repository root, don’t use working-directory for the artifact generation step, or use an absolute path like /home/runner/work/your-repo/your-repo/path/to/files.
Why it works: Understanding the execution context of working-directory is crucial. The path is always resolved from that context.

4. Wildcard Path Issues:

Diagnosis: If you’re using wildcards (e.g., *.jar, build/**/output.zip), verify that the wildcard pattern correctly matches the files at the time the action runs.
```
- name: Upload JARs
  uses: actions/upload-artifact@v4
  with:
    name: my-jars
    path: target/*.jar
```
Cause: The build process might have produced files with slightly different names (e.g., my-app-1.0.0.jar vs. my-app.jar), or no .jar files were produced at all. Or, the wildcard might be too broad or too narrow.
Fix: Be specific or use a more general pattern if necessary. Running ls target/*.jar in a run step before uploading can confirm what files match. If the build produces versioned JARs, you might need target/my-app-*.jar.
Why it works: Wildcards are powerful but require precision. The upload-artifact action uses globbing, and if no files match the pattern, it reports no files found.

5. Artifacts Uploaded with a Different Name:

Diagnosis: When downloading artifacts, if you specify a name that doesn’t match exactly how it was uploaded, it will fail. This is less common for the "No Files Were Found" error on upload, but critical for download.

# In a previous job:
- name: Upload build artifact
  uses: actions/upload-artifact@v4
  with:
    name: my-build-artifact # Uploaded with this name
    path: build/output/

# In a later job:
- name: Download artifact
  uses: actions/download-artifact@v4
  with:
    name: my-build-artefact # Typo here!
    path: ./downloaded/

Cause: A typo or inconsistent naming convention between upload and download steps, especially across different jobs or workflows.
Fix: Ensure the name parameter used in actions/upload-artifact is identical to the name parameter used in actions/download-artifact when retrieving it.
Why it works: The artifact name is the primary identifier for retrieval. Any discrepancy means the system can’t locate the specific artifact you’re asking for.

6. Artifacts Already Downloaded and Deleted:

Diagnosis: If your workflow has multiple steps that download the same artifact, and one of them uses if-no-files-found: error (the default), subsequent attempts to download that artifact might fail if it was already consumed and potentially deleted by a previous step.

- name: Download and process artifact
  uses: actions/download-artifact@v4
  with:
    name: my-data
    path: ./data/
    # This step might clean up or move files

- name: Download artifact again (fails)
  uses: actions/download-artifact@v4
  with:
    name: my-data
    path: ./backup/

Cause: The artifact is a temporary resource. Once downloaded and processed, it might not persist if subsequent steps expect it to be there but it has already been moved, deleted, or its contents altered.
Fix: Avoid downloading the same artifact multiple times unless you have a clear strategy for it. If you need the data in multiple places, download it once into a central location and then copy/move it from there. Or, ensure the artifact is re-uploaded if it’s meant to be a distinct output of a later stage.
Why it works: Artifacts are not persistent storage. They are intended for passing outputs between jobs within a workflow run. If they are consumed and no longer exist in the expected location, subsequent download attempts will find nothing.

After fixing any of these, the next error you’ll likely encounter is a Job has exceeded the maximum execution time if your workflow is taking too long to complete due to complex build processes or inefficient artifact handling.