Upload-artifact: Upload fails, appears to be looking at the wrong path. (Windows Only)

Created on 18 Dec 2019  Â·  8Comments  Â·  Source: actions/upload-artifact

Hi,

Thank you for this plugin. Everything was working correctly during the beta, however, uploading on windows appears to fail due to a project path being duplicated. I suspect the path should be d:\a\PDO\build\coverage with only one PDO folder.

Run actions/upload-artifact@master
  with:
    name: coverage-report
    path: build/coverage
##[error]Path does not exist d:\a\PDO\PDO\build\coverage
##[error]Exit code 1 returned from process: file name 'c:\runners\2.162.0\bin\Runner.PluginHost.exe', arguments 'action "GitHub.Runner.Plugins.Artifact.PublishArtifact, Runner.Plugins"'.

Most helpful comment

I made an example repo for Ubuntu, MacOS and Windows, which seems to work in all of them using the exact same rules as explained above.

So for anyone who still has problems on Windows, please add a debug step before your upload step that checks whether the files you expect actually exist and are inside the $GITHUB_WORKSPACE directory. Note I had to wrap the var in $( … ) for Windows PowerShell when I wanted to add path components.

All 8 comments

Same error:

with:
    name: mrrobot-amd64-Windows
    path: target/release/mrrobot
##[error]Path does not exist d:\a\MrRobot\MrRobot\target\release\mrrobot
##[error]Exit code 1 returned from process: file name 'c:\runners\2.163.1\bin\Runner.PluginHost.exe', arguments 'action "GitHub.Runner.Plugins.Artifact.PublishArtifact, Runner.Plugins"'.

Double repo name also on Linux (Ubuntu/Docker):

Path does not exist /home/runner/work/nodemcu-firmware-daily-vanilla/nodemcu-firmware-daily-vanilla/output

Affected repo: https://github.com/mk-pmb/nodemcu-firmware-daily-vanilla/

… so I tried :bomb: directory traversal :bomb:, using path: ../output/nodemcu_firmware.bin, and at least now there's only one repo name in the path:

Path does not exist /home/runner/work/nodemcu-firmware-daily-vanilla/output/nodemcu_firmware.bin

However, something's still wrong, because ls in the previous task can totally see that file.

2020-01-02T05:46:34.4999753Z ----- 8< --== ls /output ==-- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----
2020-01-02T05:46:34.4999925Z total 12K
2020-01-02T05:46:34.5000254Z drwxr-xr-x 2 root root 4.0K Jan  2 05:46 ./
2020-01-02T05:46:34.5000631Z drwxr-xr-x 1 root root 4.0K Jan  2 05:46 ../
2020-01-02T05:46:34.5000928Z -rw-r--r-- 1 root root   32 Jan  2 05:46 nodemcu_firmware.bin
2020-01-02T05:46:34.5001248Z ----- >8 --== ls /output (rv=0) ==-- >8 ----- >8 ----- >8 ----- >8 -----

Next I tried the branch name as 2nd subdir, but no luck either:

Path does not exist /home/runner/work/nodemcu-firmware-daily-vanilla/master/output/nodemcu_firmware.bin

Update: Looks like path should be inside of, and relative to, /github/workspace/.
Update: Yeah, that does the trick. Works for me now.

Not Windows only, it is the same for Linux machines, as well.
It is same for me as well, it appends extra repo name to the path

##[error]Path does not exist /home/runner/work/calendarview/calendarview/~/junit
##[error]Exit code 1 returned from process: file name '/home/runner/runners/2.163.1/bin/Runner.PluginHost', arguments 'action "GitHub.Runner.Plugins.Artifact.PublishArtifact, Runner.Plugins"'.

@mk-pmb sorry didn't understand what did you do exactly? Can you please elaborate further for me? :) However, my project is Android and Actions works on Ubuntu.

The exact steps that had resolved my issue were:

  1. In the path input variable specify a relative path that starts with a directory name and does not traverse up. (Wrong: specify an absolute path i.e. starts with slash. Wrong: specify a relative path that contains a .. (parent directory) segment)
  2. Treat that path as relative to $GITHUB_WORKSPACE.

Example workflow config file: in my repo I use runs-on: ubuntu-latest and for the upload action path: output/. The GITHUB_WORKSPACE environment variable inside the runner usually is set to /github/workspace, so usually my script creates a directory /github/workspace/output and stores the artiface file(s) in there.

I made an example repo for Ubuntu, MacOS and Windows, which seems to work in all of them using the exact same rules as explained above.

So for anyone who still has problems on Windows, please add a debug step before your upload step that checks whether the files you expect actually exist and are inside the $GITHUB_WORKSPACE directory. Note I had to wrap the var in $( … ) for Windows PowerShell when I wanted to add path components.

Hi @mk-pmb

Thanks for the detailed explanation. It helped me indeed! You saved my day!

This issue has been fixed with v2! The path should now properly resolve on Windows.

I ran this bit of YAML to confirm the behavior so it's now identical between Windows/Linux/Mac

on:
    push:
        branches:
            -   master

jobs:
    job_example_upload_ubuntu:
        runs-on: ubuntu-latest
        name: '[Ubuntu] Upload artifacts'
        steps:
            -   run: 'mkdir --parents results/artifacts'
            -   run: 'env | grep GITHUB_ | sort > results/artifacts/ci-env.txt'
            -   uses: actions/upload-artifact@v2
                with:
                    name: artifacts_from_ubuntu
                    path: results/artifacts/

    job_example_upload_macos:
        runs-on: macos-latest
        name: '[MacOS] Upload artifacts'
        steps:
            -   run: 'mkdir -p results/artifacts'
            -   run: 'env | grep GITHUB_ | sort > results/artifacts/ci-env.txt'
            -   uses: actions/upload-artifact@v2
                with:
                    name: artifacts_from_macos
                    path: results/artifacts/

    job_example_upload_windows:
        runs-on: windows-latest
        name: '[Windows] Upload artifacts'
        steps:
            -   run: 'mkdir results'
            -   run: 'mkdir results\artifacts'
            -   run: 'dir $( $GITHUB_WORKSPACE )'
            -   run: 'env | Where-Object {$_ | Select-String "GITHUB_"} | sort > results\artifacts\ci-env.txt'
            -   uses: actions/upload-artifact@v2
                with:
                    name: artifacts_from_windows
                    path: results/artifacts/

I updated my example repo to show the new environment variables, instead now I get strange provisioning errors.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

panos picture panos  Â·  3Comments

Niceplace picture Niceplace  Â·  5Comments

davidmoremad picture davidmoremad  Â·  6Comments

Tyrrrz picture Tyrrrz  Â·  5Comments

aparcar picture aparcar  Â·  5Comments