Omitting the enclosing directory

[chancancode]

This is sort of similar to #3, but perhaps has a slightly easier path.

Right now, the action only support uploading a folder. This is not ideal, but I'm able to work with it. However, when zipping up the content, it includes the enclosing directory itself, resulting in a structure like this when downloading the zip file (from the UI, or from the download action):

some-folder.zip
└── some-folder
    ├── nested-folder
    │   └── some-nested-file.txt
    ├── some-file.txt
    └── another-file.txt

This is unnecessary for my use case. Ideally, I would want to zip file to have this structure:

some-folder.zip
├── nested-folder
│   └── some-nested-file.txt
├── some-file.txt
└── another-file.txt

The difference being that the enclosing folder ("some-folder") is no longer included in the zip file.

In my use case, this is important. I'm using GH Actions to build a chrome/firefox extension. Their submission form accept a zip file with a known structure. If I can omit the enclosing folder, I can always get what I want by restructuring the content of the folder I'm passing to this action. With the current setup, there is no way to accomplish that since there will always be an extraneous folder at the root of the zip file, which is not allowed.

Instead, I'll have to create the zip file in the format I wanted, put it into a folder, pass it to this action, then later download the zip-file-containing-a-folder-containing-a-zip-file from the UI, then upload that to the submission form.

Of course, it would be even nicer if this action can take an arbitrary list of files, including glob patterns, etc. But even without any of that, if we can omit the enclosing folder at the root, it is sufficient to create arbitrary artifacts archive (but making an additional temporary folder and copying things around).

[welwood08]

@chancancode Since you mentioned downloading the artifact from the UI and then manually uploading to the addon submission form, Firefox Addon Action and Chrome Addon Action might be useful in your particular situation.

Still, it would be nice to be able to specify as an option whether the artifact should include the root folder.

[mk-pmb]

Similar to #39 (ZIP in ZIP), there should just be an option to take our files verbatim. Maybe just a flag verbatim: true for devs who think they know what they want.

[konradpabjan]

We've implemented a change that removes the the root directory (artifact name) when downloading the zip of an artifact.

https://github.blog/changelog/2020-01-14-github-actions-changes-to-artifact-download-experience/

This is currently turned on for a few users for testing/validation but we plan on rolling this out to everyone over the next few days

The artifact name (root directory) is more of an implementation detail in terms of how we store the artifact behind the scenes so it shouldn't have been included to begin with.

[mk-pmb]

Thanks a lot! A very good improvement.

[mk-pmb]

Am I doing it wrong? In this actions run I used

uses: actions/upload-artifact@v1
with:
    name: esp32_nodemcu_firmware
    path: output/

Now the files are no longer packed into a directory called esp32_nodemcu_firmware, but output. I guess someone accidentially removed the path prefix stripping.

[tonyarnold]

Oh man, I was using that feature to capture Apple platform bundles like .app and .xcarchive. Now my captured artifacts aren't valid anymore.

Is there an option to re-enable this somehow? Perhaps omitting the directory could be enabled by adding a trailing slash to the path, such as shown above? (and as seems to be common to other CLI tooling)

[mk-pmb]

Is there an option to re-enable this somehow?

If you need an enclosing directory, in the current version just make a directory with the appropriate name, move the files inside it, and put the directory name as the artifact. You can use this actions run as an example: It creates a directory named "output" in the repo, gives path: output/ as the artifact source, and thus the artifact will consist of that directory.

In future versions, when they finally manage to strip the prefix, you could do like I try to for weeks: Make an output directory, put there the files you want (in your case, your top-level directory). So if your package should be a zipball with the directory "my-app" inside it, you'd move the files into /path/to/your/workspace/output/my-app, set path: output/, and everything inside that (i.e., the my-app directory) would be packaged.

[tonyarnold]

I feel like I'm missing something basic here. If I do the following:

- name: "Capture Xcode archive as an artifact"
  uses: actions/upload-artifact@v1
  with:
    name: Reveal.xcarchive
    path: build/XcodeArchives/Reveal.xcarchive

When I download the file in Safari to my Mac, it extracts the contents of that path, completely eliding the top-level bundle.

I expect to get a decompressed file named Reveal.xcarchive - instead, I get a folder named Contents (which is the top-level folder within Reveal.xcarchive from the CI server).

Yep, I can change the step to be:

- name: "Capture Xcode archive as an artifact"
  uses: actions/upload-artifact@v1
  with:
    name: Reveal.xcarchive
    path: build/XcodeArchives/

But that means that I need to ensure that there is nothing else in that directory at this stage.

I don't think this change has been well thought through - perhaps it shouldn't have been rolled out until the ability to filter/exclude/include was added to this action? My workflow is now busted, and I'm not entirely sure how to fix it without adding a bunch of needless steps to move files around before capturing them.

[mk-pmb]

While I agree that it would be nicer if Github could provide us with ways to package single files (so you could pack your zipball yourself), fortunately your

But that means that I need to ensure that there is nothing else in that directory at this stage.

hurdle has an easy solution: Rename the directory, create a clean new directory, move your wanted directory in.

how to fix it without adding a bunch of needless steps

Yeah well, considering how much dev time Github seems to allocate to this project, consider yourself one of the luckier people. I wish my problem with the upload action were solved as easy as just adding a few jump-through-hoops extra commands. :-(

In the end I think it's a luxury problem to complain about the few dirty spots in a nice (and free as in beer) product. As far as I understood the help pages, Github actions does support encrypted secrets. So if we were more annoyed than lazy, we could just create an FTP account somewhere and have our actions upload the packages there.

[tonyarnold]

In the end I think it's a luxury problem to complain about the few dirty spots in a nice (and free as in beer) product.

GitHub Actions isn't free for my use case. My company is paying for the use of this product both via the team plan's costs, and the incoming costs of builds when we inevitably use up the included minutes (macOS builds are charged at a 10x multiplier from linux builds).

I'll do my best to say this politely, and then leave this conversation be: This issue tracker is here for users (such as you and I) to report issues, which is what I've done. I don't appreciate being told that the issues I took the time to raise are a "luxury problem".

@mk-pmb I hope that you get the resolution that you want — or a workaround — for the issues you've raised.

[mk-pmb]

I don't appreciate being told that the issues I took the time to raise are a "luxury problem".

Indeed, I apologize then. I was unable to imagine that this service level also applies to paying customers. Totally shifts the deal.

[mk-pmb]

Is this rolled out to everyone meanwhile? Especially for guests / not logged in visitors.