Support $HOME in Path Argument

[ccjernigan]

This is a feature request to support $HOME in the path.

I'm trying to use the upload-artifact action as a step in a CI build. Most of my other steps are saving and storing files based on paths relative to $HOME, so it makes sense to be able to do the same here.

The workaround currently is to hardcode the path.

So currently I do something like this:

- uses: actions/upload-artifact@v1
  with:
      name: artifacts.zip
      path: /home/runner/my_file

But would like to do this:

- uses: actions/upload-artifact@v1
  with:
      name: artifacts.zip
      path: ${HOME}/my_file

[eine]

@ccjernigan, I think that the default path is HOME. Hence, path: my_file might work. Did you try it? Note that my_file must be a directory. It is not possible to upload files. Please, see #3.

[ccjernigan]

I tried changing it to path: my_dir and the path I'm seeing in the logs doesn't seem to match $HOME/path. Instead I think it is defaulting to the checked out repo.

[eine]

Indeed... This is the runner context on a regular shell step:

{
  "os": "Linux",
  "tool_cache": "/opt/hostedtoolcache",
  "temp": "/home/runner/work/_temp",
  "workspace": "/home/runner/work/REPO_NAME"
}

And the GitHub context contains:

  "workspace": "/home/runner/work/REPO_NAME/REPO_NAME",
  "action": "run1",
  "event_path": "/home/runner/work/_temp/_github_workflow/event.json"

The point is that I don't know if you can rely on /home/runner. As explained in https://help.github.com/en/articles/virtual-environments-for-github-actions#filesystems-on-github-hosted-machines:

The GitHub-specific paths on virtual machines that run JavaScript and shell script actions are not static. GitHub provides environment variables that you can use to construct file paths for the home, workspace, and workflow directories used by GitHub Actions.

Then, according to https://help.github.com/en/articles/workflow-syntax-for-github-actions#jobsjob_idstepsworking-directory, the following step option might work:

  working-directory: ${{ home }}

[ccjernigan]

I tried setting working-directory: ${{ home }} but that didn't seem to work either. I got Unexpected value 'working-directory'

The reason for filing this issue is so that we don't have to rely on /home/runner or some other hardcoded path which might break in the future.

I realize that most of the time, artifacts from the build will be in the checked out repo directory. In my case, I have a multi-module Gradle build so I want to collect artifacts across a series of directories. I'm doing a find with wildcards and then copying to another directory, and it seems less weird to create that copy in the home directory rather than within the git repo, to avoid namespace between the git repo contents and temp directories created by the CI script.

[eine]

@ccjernigan, just to make it clear, I totally agree with this issue/request. My comments above were an effort to find a currently supported workaround that could have filled your requirements. Unfortunately, it seems that there is none.

I'm doing a find with wildcards and then copying to another directory, and it seems less weird to create that copy in the home directory rather than within the git repo, to avoid namespace between the git repo contents and temp directories created by the CI script.

I apply a similar procedure, but I use a sibling directory, not a children nor any 'arbitrary' location. E.g.:

- run: |
    mkdir ../artifacts
- uses: actions/upload-artifact@v1
  with:
      name: artifacts.zip
      path: ../artifacts

Of course, this relies on run and uses: actions/upload-artifact being executed in exactly the same workspace. I don't know if this is officially guaranteed.

Apart from that, regarding wildcards and reorganizing the content with find/cp, you might want to upvote this comment in #3.

[natario1]

Not adding much to the discussion, but it would be nice to be able to use any env variable (not just HOME).

[MaxPeal]

+1

[konradpabjan]

We've added support for $HOME using tilde expansion in the v2-preview. You can check it out here:
#62

Using env variables as input to actions was added a while back ago (this was a limitation that was effecting all actions). I've updated our documentation with examples on how to use env variables and tilde expansions: https://github.com/actions/upload-artifact/tree/v2-preview#environment-variables-and-tilde-expansion

[myitcv]

Thanks for the update.

Using env variables as input to actions was added a while back ago

Just to confirm, according to this page:

The env context syntax allows you to use the value of an environment variable in your workflow file. If you want to use the value of an environment variable inside a runner, use the runner operating system's normal method for reading environment variables.

i.e. you cannot arbitrarily expand environment variables as input values, for example.

[konradpabjan]

v2 artifact upload has been released and with it there is support of tilde expansion. TheREAMDE also has an example on how to use this along with env variables: https://github.com/actions/upload-artifact#environment-variables-and-tilde-expansion

[Bilge]

That's great, for this action specifically, but generally being unable to reference $HOME in YAML configuration is still problematic for literally every other action out there.

[nonesky666]

aha hm i see thanks

…

On Mon, 6 Nov 2023 at 17:11, Bilge ***@***.***> wrote: That's great, for this action specifically, but generally being unable to reference $HOME in YAML configuration is still problematic for literally every other action out there. — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXNMDTZBOU2QZ6C3FVUMXITYDED3ZAVCNFSM4IUI3AHKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZZGUZTCMRRGI2A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>