Put cross-platform binaries of the substrate node, the ones built by cargo build --release, to Github Releases (or some other platform).
Use cases:
substrate --dev without spending 2h to build itRequests:
Right now we have only v1.0 branch releases on Github releases, so should the binaries be for this branch only?
For other Ci's purposes (Substrate Light UI), you can take the binary you need straight from releases.parity.io.
Binaries for v1.0 is good (and in the future, all 1.* releases I suppose).
According to https://github.com/paritytech/devops/issues/326, we have https://crates.parity.io/substrate/index.html. Which also can be used to store releases.
linux binaries can also be found on s3 e.g. https://releases.parity.io/substrate/x86_64-debian:stretch/latest-v1.0/substrate resp. https://releases.parity.io/substrate/x86_64-debian:stretch/latest/ for latest master build.
@gabreal Thanks for those links, that's great to know. How can I know which packages are available there? For example is there an rpm? 32-bit builds? anything for mac or windows?
Is there a place to browse? For example, when downloading debian, I can look through what they have available (https://cdimage.debian.org/debian-cd/).
I'm not saying there needs to be or should be all that many packages yet, I just want to know what we're dealing with, and direct users to the right spot.
@JoshOrndorff right now substrate is being built for x86_64-unknown-linux-gnu and partly for wasm32-unknown-unknown.
Please request the architectures you need one by one, it's going to take some time for each.
I would definitely put macos and windows as the next top-priority platforms to build binaries for.
@amaurymartiny would you mind creating detailed issues for them?
I've opened separate issues the OSX and Windows builds that @amaurymartiny requested and one for RPM packages that I'm requesting, so I'm closing this one.
Possible places to publish these packages:
Is there a place to browse?
unfortunately no. you can access every file that you know it exists. It's a s3 bucket.
Reopening. Better to put all requests in one issue.
If we do build for Windows I suggest that we also run the test (or at least build) for Windows so we can detect problems during the PRs. Example here of a problem that can occur: https://github.com/paritytech/substrate/pull/4692#discussion_r372333092
Most helpful comment
Reopening. Better to put all requests in one issue.