Maintain path relative to root folder

[thenewguy]

It would be helpful if my artifact would not squash the directory structure. For example,

- name: Archive production artifacts
        uses: actions/upload-artifact@v2
        with:
          name: assets
          retention-days: 5
          path: ./root/relative/path/to/my/file*

I end up with a zipfile containing file.js and file.css. What I want is a zipfile containing root/relative/path/to/my/file.js and root/relative/path/to/my/file.css

-- edit --

The reason for this is so that I can unpack it on my project file for use in the next job

-- edit --

This command produces the behavior I am looking for. I am having to manually pack & unpack it. But this gives you the idea:

zip artifact.zip ./root/relative/path/to/my/file*

This gives me a zip file with root/relative/path/to/my/file.js and root/relative/path/to/my/file.css

[rcowsill]

It'd be great to have an option to specify the root path to use for the artifacts. It could be optional, and if not specified the current behaviour would be used.

As a workaround in the meantime you can make an empty file in root/ and include it in the artifact. That should force the action to produce this directory structure:

empty.txt
relative
└ path
  └ to
    └ my
       file.css
       file.js

[konradpabjan]

This behavior is documented: https://github.com/actions/upload-artifact#upload-using-multiple-paths-and-exclusions

The reason why only file.js and file.css are included without a root directory is because you're using a wildcard pattern and it gets cutoff there.

If you do something like path: ./*/relative/path/to/my/file* then it should include the full path.

[aminya]

There should be an option to maintain the paths. The reason is that if you use download-artifact later, you have to manually move the files from the ./artifact folder to place them in the correct path.

      - name: Upload built files
        uses: actions/upload-artifact@v2
        with:
          path: |
            ./dist

      - name: Download articats
        uses: actions/download-artifact@v2
      - name: Place artifacts
        shell: bash
        run: |
          rm -rf dist
          mv artifact/* ./

[tulsishell]

I found a way around this - include one other file in your artifact which doesn't have the same base path as all the other files. It should be in a completely different folder from the root itself. This way the action doesn't find any least common ancestor of all the search paths and gives you complete directory structure. :)

[mgebundy]

Thanks for the workaround @rcowsill & @tulsishell

I would love to see a simple option for maintaining paths, it's causing similar issues on our end and I'm not even interested in using wildcards.

Edit: this workaround also means I can't use if-no-files-found: error at all, since there will ALWAYS be an dummy file included in the upload.

[asos-tomp]

I found a way around this - include one other file in your artifact which doesn't have the same base path as all the other files. It should be in a completely different folder from the root itself. This way the action doesn't find any least common ancestor of all the search paths and gives you complete directory structure. :)

Frustratingly, an approach that can't be used with parallel jobs I assume, since unless each choses a unique "one other file", the mentioned 503 errors will kick in.

[retorquere]

Frustratingly, an approach that can't be used with parallel jobs I assume, since unless each choses a unique "one other file", the mentioned 503 errors will kick in.

I'm running this to keep the dir structure

mkdir artifacts
mkdir .artifacts
mktemp .artifacts/artifacts.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

and then specify both for upload. Which is... not great, but works.

[Naman-Kumar-Sinha]

Frustratingly, an approach that can't be used with parallel jobs I assume, since unless each choses a unique "one other file", the mentioned 503 errors will kick in.

I'm running this to keep the dir structure

mkdir artifacts
mkdir .artifacts
mktemp .artifacts/artifacts.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

and then specify both for upload. Which is... not great, but works.

Thanks for the tip @retorquere! This worked well. I wonder if it can be an opt-in functionality in this action.

[ken-cdit]

Can't believe there is still no explicit option for this.