Upload-artifact: Support tar.xz

[xenoterracide]

reason, improved compression, improved upload, improved download times. suggested structure is just to allow for expansiveness if needed

     with:
         archive: tar
         compression: xz

recently testing the new glob feature, and having problems... I also tried doing it with tar.

time to compress tar.xz and wrap in zip and upload 7s, 1.4MB
time to compress zip and upload 1m 15s, 21.5MB

[yacaovsnc]

Thanks for the feedback and it's an option we have debated internally. The mental model we use around artifacts system is to treat it as a "file systems", i.e. each artifact is a folder, and we can upload multiple files to the folder. This is the most flexible model as some use cases require updating the same artifact through different jobs and in the end produce the final result. In this model, creating an archive and compressing the archive should be done prior to creating the artifacts.

We understand this option would simplify some use cases, and at the same time it introduces complexity in many other scenarios so ultimately we opted to reduce complexity by not providing the archiving option.

[MCOfficer]

Could the action at least batch-upload files with tar internally? We have a MacOS app with over 3k individual files, and it takes over 3 minutes to upload - presumably because files are uploaded sequentially.

Edit: checked the code, it's 2 files in parallel.

If we tar the entire thing beforehand, it slips through the pipe in a matter of seconds. The action could do the same trick internally to massively speed up folder uploads (and, to some extend, downloads). The backend could just extract the tar and act as if those files had been sent one by one.