Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[build] Refine and consolidate release artifacts #49

Open
cbeams opened this issue Jul 30, 2021 · 0 comments
Open

[build] Refine and consolidate release artifacts #49

cbeams opened this issue Jul 30, 2021 · 0 comments
Assignees

Comments

@cbeams
Copy link
Owner

cbeams commented Jul 30, 2021

Following the merge of #47 and #48, the early-access release at 2eca603 contains the following 52(!) artifacts:

bisq-2.0.0-early-access-1.x86_64.rpm
bisq-2.0.0-early-access-1.x86_64.rpm.asc
bisq-2.0.0-early-access-linux-x86_64.zip
bisq-2.0.0-early-access-linux-x86_64.zip.asc
bisq-2.0.0-early-access-osx-x86_64.zip
bisq-2.0.0-early-access-osx-x86_64.zip.asc
bisq-2.0.0-early-access-windows-x86_64.zip
bisq-2.0.0-early-access-windows-x86_64.zip.asc
bisq-2.0.0-early-access.exe
bisq-2.0.0-early-access.exe.asc
bisq-2.0.0-early-access.msi
bisq-2.0.0-early-access.msi.asc
bisq-2.0.0-early-access.pkg
bisq-2.0.0-early-access.pkg.asc
bisqd-2.0.0-early-access-1.x86_64.rpm
bisqd-2.0.0-early-access-1.x86_64.rpm.asc
bisqd-2.0.0-early-access-linux-x86_64.zip
bisqd-2.0.0-early-access-linux-x86_64.zip.asc
bisqd-2.0.0-early-access-osx-x86_64.zip
bisqd-2.0.0-early-access-osx-x86_64.zip.asc
bisqd-2.0.0-early-access-windows-x86_64.zip
bisqd-2.0.0-early-access-windows-x86_64.zip.asc
bisqd-2.0.0-early-access.exe
bisqd-2.0.0-early-access.exe.asc
bisqd-2.0.0-early-access.msi
bisqd-2.0.0-early-access.msi.asc
bisqd-2.0.0-early-access.pkg
bisqd-2.0.0-early-access.pkg.asc
bisqd_2.0.0-early-access-1_amd64.deb
bisqd_2.0.0-early-access-1_amd64.deb.asc
bisqfx-2.0.0-early-access-1.x86_64.rpm
bisqfx-2.0.0-early-access-1.x86_64.rpm.asc
bisqfx-2.0.0-early-access-linux-x86_64.zip
bisqfx-2.0.0-early-access-linux-x86_64.zip.asc
bisqfx-2.0.0-early-access-osx-x86_64.zip
bisqfx-2.0.0-early-access-osx-x86_64.zip.asc
bisqfx-2.0.0-early-access-windows-x86_64.zip
bisqfx-2.0.0-early-access-windows-x86_64.zip.asc
bisqfx-2.0.0-early-access.dmg
bisqfx-2.0.0-early-access.dmg.asc
bisqfx-2.0.0-early-access.exe
bisqfx-2.0.0-early-access.exe.asc
bisqfx-2.0.0-early-access.msi
bisqfx-2.0.0-early-access.msi.asc
bisqfx_2.0.0-early-access-1_amd64.deb
bisqfx_2.0.0-early-access-1_amd64.deb.asc
bisq_2.0.0-early-access-1_amd64.deb
bisq_2.0.0-early-access-1_amd64.deb.asc
bisq_2.0.0-early-access.tar.gz
bisq_2.0.0-early-access.zip

As discussed with @aalmiray, I'd like to make a couple key changes:

Consolidate checksums and signatures into a single file

Similar to the way Bitcoin Core does it. See https://bitcoincore.org/bin/bitcoin-core-0.21.1/ for an example. I'll create a separate issue for doing this, but wanted to mention it here. This cuts way down on artifacts, and doesn't hurt anything from a security point of view. If the checksums are correct, and you trust the signer, then you trust that they signed the single checksums file and you don't need a .asc for every artifact. See "MacOS verification instructions" at https://bitcoincore.org/en/download/ for an example of how this works.

Consolidate artifacts into a smaller set

The idea here is to provide two main tiers of distribution artifacts:

  1. High-level installers for the standalone Bisq(FX) GUI. This is the entry point for most users, and as they get more sophisticated they can understand how to run a separate daemon, work the cli, etc.
  2. Comprehensive archive distributions that contain all bisq* binaries. These artifacts provide one-stop shopping for power users, containing everything they'll need to run the cli, gui, daemon (and eventually webapp)

Provide high-level installers only for Bisq(FX) GUI

Provide high-level installers, e.g. dmg and .msi files only for the BisqFX GUI, and name these files bisq-${version}-osx.dmg, bisq-${version}-win64.msi. Note that the name of the file is not bisqfx-*, but actually just bisq-*. The reason for this is that while we do have three separate binaries, we don't want to expose the 'fx' suffix to higher-level end users. The only users that should care about this distinction are those that are actually also running the daemon and/or cli. This approach is very similar to the way that Bitcoin Core has a number of different binaries, including bitcoin-cli, bitcoind and bitcoin-qt, but bitcoin-${version}-osx.dmg contains only the bitcoin-qt binary (which is actually named Bitcoin Core) and the dmg artifact name is the unqualified bitcoin, not bitcoin-qt.

Let's look at the Bitcoin Core dmg distribution at https://bitcoincore.org/bin/bitcoin-core-0.21.1/bitcoin-0.21.1-osx.dmg in more detail.

Notice the naming: bitcoin-0.21.1-osx.dmg. As mentioned, it's just bitcoin not bitcoin-qt.

When mounting that dmg, we get contents that look like the following:

$ ls /Volumes/Bitcoin-Core/Bitcoin-Qt.app/Contents/MacOS/
Bitcoin-Qt

And this is what the user sees graphically:

image

So whenever the user is interacting with the app that they installed via that dmg, they see "Bitcoin Core", never just 'bitcoin' or 'bitcoin-qt'

Similarly, for our own Bisq-${version}-osx.dmg file, we would want to have contents looking like the following:

$ ls /Volumes/Bisq/Bisq.app/Contents/MacOS/
Bisq

or possibly:

$ ls /Volumes/Bisq/BisqFX.app/Contents/MacOS/
BisqFX

So long as the application name the user sees when interacting with the app is simply "Bisq", as shown here:

image

Provide traditional distribution archives that bundle all bisq* executables

As seen at https://bitcoincore.org/bin/bitcoin-core-0.21.1/, Bitcoin Core provides tar.gz distributions for several architectures, including osx. Let's look at the (partial) contents of https://bitcoincore.org/bin/bitcoin-core-0.21.1/bitcoin-0.21.1-osx64.tar.gz:

$ tar -xzf bitcoin-0.21.1-osx64.tar.gz 
$ tree bitcoin-0.21.1/bin
bitcoin-0.21.1/bin
├── bitcoin-cli
├── bitcoin-qt
├── bitcoin-tx
├── bitcoin-wallet
├── bitcoind
└── test_bitcoin

Likewise, when unpacking the the windows distribution at https://bitcoincore.org/bin/bitcoin-core-0.21.1/bitcoin-0.21.1-win64.zip, we see something very similar:

$ unzip bitcoin-0.21.1-win64.zip
$ tree bitcoin-0.21.1/bin/
bitcoin-0.21.1/bin/
├── bitcoin-cli.exe
├── bitcoin-qt.exe
├── bitcoin-tx.exe
├── bitcoin-wallet.exe
├── bitcoind.exe
└── test_bitcoin.exe

In Bisq's case, such a distribution would look something like this:

$ tar -xzf bisq-${version}-osx.tar.gz
$ tree bisq-${version}/bin
├── bisq (cli)
├── bisqd
└── bisqfx

(jlink-produced java binary, etc omitted here)

Final set of archives / assets

So the final set of release artifacts would read something like the following:

Bisq-${version}-osx-x86_64.dmg
Bisq-${version}-osx-aarch64.dmg
Bisq-${version}-win64.msi
bisq-${version}-linux-x86_64.tar.gz
bisq-${version}-linux-aarch64.tar.gz     # ARM distro is key for running on raspberry pi
bisq-${version}-osx-x86_64.tar.gz
bisq-${version}-osx-aarch64.tar.gz
bisq-${version}-win64.zip
bisq-${version}.tar.gz                   # source code
bisq-${version}.zip                      # source code
checksums_sha256.asc                     # single consolidated file like bitcoin does

Notes:

  • I capitalized Bisq in the dmg and msi installers just to call out the fact that this has been our current naming scheme in the 1.x line. We can change it,but should be a conscious decision to do so.
  • Regarding .deb, .rpm and .pkg files, I'm not sure whether we should just hold off on this and see what users need first. I'm not sure whether multiple binaries, e.g. the bisq cli and bisqd daemon can be bundled and installed within the same .deb/.rpm. In any case, I'd rather prioritize getting Homebrew, Snap, and Scoop set up properly first.
  • I realize that the aarch64 osx variants will have to be manually uploaded for now, and they would need their own '.asc' files for verification, since they won't be able to be included in the single checksums file.
  • Same thing with the ARM linux distribution. GitHub doesn't have ARM runners, so we'd need to set up our own self-hosted runner, or otherwise manually publish that artifact. I wanted to mention the need for that distro here, but it's out of scope for this particular issue to deal with it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants