Bundle Saturn L2 node

[bajtos]

• Add a build step to download Saturn L2 Node binaries from project's GitHub Releases
• Modify Electron Builder configuration to include Saturn L2 binary in packaged Resources
• Add a dummy main script to print the path of the Saturn L2 Node binary and verify that the path exists

Close #19

[lidel]

• 🟢 including binary inside of DMG should be fine
  • this is actually an easy hack to ensure your daemon binary is correctly notarized on macOS, even when upstream binary does not include signing/notarization metadata – as part of notarization step on CI everything inside of DMG gets hashed and "blessed" by Apple
• ⚠️ fetching release artifacts will get rate-limited and your builds will fail (example) – i think you can fix this by using GITHUB_TOKEN provided by Github Action env (raises request limit to 1k / hours)

[bajtos]

Thank you, @lidel! Your insights are always helpful 👏🏻

I have two more questions if you don't mind.

(1) In the current implementation, I am downloading release archives for all combinations of (platform, architecture). This would be useful if we were cross-compiling for multiple platforms from the same source tree. However, IIUC, our build setup is always building for the current platform & architecture only. That means we can download only one release archive. Is it a reasonable assumption?

(2) Do you happen to know what's the story for building Electron for M1 Macs?

• I am working on a darwin-arm64 machine, building darwin-arm64 package works well locally.
• The next step is to build darwin-arm64 as part of our GitHub Actions release workflow. I believe GHA does not offer darwin-arm64 runners yet, one has to setup a self-hosted runner. But then do we need that? Isn't it possible to build darwin-arm64 package on an x64 host?
• Finally, there are two options how to package macOS applications - either provide two installers, one for x64 another for arm64, or create a universal app bundling both flavours into a single binary. To do that, we need to build both x64 & arm64 versions from the same source tree, which brings me back to the first question whether it's ok to download only one release archive of saturn-l2.

Support for darwin-arm64 is most likely out of scope of MVP, I created a new GH issue for that: #35

[bajtos]

That means we can download only one release archive. Is it a reasonable assumption?

Based on what I found regarding Apple M1 builds, I am leaning towards downloading all architectures (x64, arm64) for the current platform (e.g. darwin).

[bajtos]

In 8b9208e, I reworked the implementation to use GITHUB_TOKEN when calling GitHub and fetch release archives for the current platform only.

Using the dist files attached to GHA run, I verified on the following platforms that Station contains saturn-l2 binary that can be executed: MacOS M1, Windows x64.

[lidel]

• Re (1) **binary per platform: ok **

  • we can download only one release archive. Is it a reasonable assumption?

    • yes, that would be ideal – in Brave, they fetch platform specific go-ipfs binary and run native ARM code on M1 Macs
    • in ipfs-desktop we use npm-go-ipfs which takes care of fetching correct binary from https://dist.ipfs.io/go-ipfs/ (windows/linux/darwin), but it recently got tricky when it comes to darwin (macOS), and afaik we are still using Intel binary for go-ipfs in DMG I think (notes below)
• Re (2) macOS: apple silicon comes with caveats

  • I am leaning towards downloading all architectures (x64, arm64) for the current platform (e.g. darwin).

    • sounds like sensible approach
    • there is some prior art in feat: kubo 0.29 and native apple silicon ipfs/ipfs-desktop#1856 around producing "universal" DMG that has Electron for both Intel and Apple Silicon, but that PR is missing code that decides which version of go-ipfs binary should be used when Apple Silicon runtime is detected
      • in other words, you can produce universal DMG which will have both Intel and Apple Silicon versions of Electron, but you need to also include both versions of all additional binaries you embedd inside of DMG and have code that decides which on e should be run
    • NOTE: if you don't use Universal DMG, or if you have universal DMG but only with two versions of electron, but only Intel version of daemon binary, then it will still work on Apple Silicon (M1) but it will require Rosetta (which could be missing, and cause issues like this)