search

taiki-e / upload-rust-binary-action

GitHub Action for building and uploading Rust binary to GitHub Releases.
Apache License 2.0
246 stars 22 forks source link

Support more archive formats #6

Open taiki-e opened 3 years ago

taiki-e commented 3 years ago
joepio commented 3 years ago

No archive would be awesome :)

samtay commented 1 year ago

No archive would be awesome :)

Seconded! My use case is that I want the user to be able to run a very portable sh install.sh that fetches binaries, and I don't want to make any assumptions about what archive tools they have installed.

damooo commented 1 year ago

Supporting upx will enable shipping really consise binaries.

matiaskorhonen commented 3 months ago

Supporting DMG on macOS would be nice (especially as DMGs support stapling the notarization)

create-dmg might be helpful for this…

taiki-e commented 2 months ago

Btw, "no archive" is not yet officially supported (https://github.com/taiki-e/upload-rust-binary-action/issues/6 is tracking issue for it), but it is considered possible to work around that limitation by using the asset option.

taiki-e commented 2 months ago

I think there are two possible APIs here.

One is to deprecate the existing tar option and add a tar-gz option which means the same thing, and then will add options such as:

with:
  tar-gz: unix     # .tar.gz (alias: tar, default: unix)
  tar-bz2: none    # .tar.bz2 (default: none)
  tar-xz: none     # .tar.xz (default: none)
  zip: windows     # .zip (default: windows)
  no-archive: none # binary with no archive (default: none)
  dmg: none        # .dmg (default: none)
  deb: none        # .deb (default: none)
  upx: none        # upx (default: none)
  # etc...

This should be consistent with existing APIs and very easy to add implementations.

The second is to add an option for comprehensive file formatting. Something like:

with:
  format: tar.gz, tar.bz2, tar.xz, zip, no-archive # etc...

This is not consistent with existing APIs and would likely need to be made mutually exclusive.

I don't have a strong opinion on which one to adopt, and was going to discuss it with who said they were interested in working on this issue, but since no one seems to be interested in working on this issue, I'll just leave the idea here.

matiaskorhonen commented 2 months ago

If there are breaking changes coming, one thing I'd quite like to see is more granularity for the archive selection.

For example, I'd like to have be able to select zip for Windows and Mac but tar.gz for linux. Or zip for Windows, dmg for Mac, and tar.gz for linux.

taiki-e commented 2 months ago

@matiaskorhonen

Unless we change the defaults, adding variants other than unix and windows doesn't break anything in particular. For example, even if we add the variants linux and macos, we can implement the variant unix to mean linux,macos,freebsd,etc., as-is.

Or do you want a completely different API?

matiaskorhonen commented 2 months ago

Ah, I'd have no problem if that could be accomplished with the existing API. I just assumed that it would cause some breakage…