Use CLI via standalone binary package #1878
Conversation
…elease-pr CD; fixed docker lock for packaged cli tests
krisbitney
requested review from
dOrgJelli,
nerfZael and
namesty
as code owners
bin/polywrap-linux-arm64
Outdated
There was a problem hiding this comment.
i guess these binaries should not be committed but rather attached in the releases when it happens, as mentioned in the description of the PR
There was a problem hiding this comment.
The requirements are that they need to be able to be fetched via curl
My understanding is that releases can't be fetched via http url, so I did it this way
There was a problem hiding this comment.
gotcha, so the user experience I was thinking for this was inspired by how foundry does things:
- in their releases, they add the assets compressed (example of a release here)
- they create a script to be run in bash and store it as an
installfile - users can easily download this script and run it by doing a
getrequest to a url (https://book.getfoundry.sh/getting-started/installation#using-foundryup)
user may do something like: curl -L polywrap.toolchain.com | bash and just do polywrap codegen (or any CLI command)
There was a problem hiding this comment.
That sounds really fantastic. I'll set it up!
There was a problem hiding this comment.
glad that made sense 😄
few thoughts:
- for now we can just do
curl https://raw.githubusercontent.com/polywrap/cli/kri/polywrap-executable/path-to-install/ -L | bashand be able to dopolywrap -v(we can add any cool url after) - in the swift client, we have a workflow release that converts a folder into a
zipand then it adds it as an "asset" of the release; we probably should do something like this to push the binaries?
There was a problem hiding this comment.
I added the binaries to the release. We should be good to go there. I need to make some changes to how the binaries are named, though.
| @@ -272,3 +272,65 @@ jobs: | |||
| - name: Test CLI JS | |||
| run: yarn test | |||
| working-directory: ./packages/js/cli | |||
|
|
|||
| Test-Cli-Standalone-Package: | |||
There was a problem hiding this comment.
i think we should create three different jobs that run in each platform we want to support, macos-latest, windows-latest and ubuntu-latest; and run yarn test:pkg
another interesting approach: build a wrapper without having node js installed? just thinking out loud here 😋
There was a problem hiding this comment.
You're right that I need to update the CI/CD to build the binaries correctly. I don't think we need separate platforms, though.
Per https://github.com/vercel/pkg#targets:
To be able to generate executables for all supported architectures and platforms, run pkg on a Linux host with binfmt (QEMU emulation) configured and ldid installed.
There was a problem hiding this comment.
I will work on this on Monday
There was a problem hiding this comment.
NOTE: running "macos" & "windows" containers in CI was not possible last time I checked. We need to spin-up docker containers within our CI, and this isn't supported by these container options on GitHub (or at least it wasn't in the past).
But I agree we are definitely lacking e2e tests for mac & windows, should see if GitHub has improved this, could be better supported now :P
There was a problem hiding this comment.
they actually support it now, in swift client we use macos-latest and windows-latest is also supported https://github.blog/changelog/2022-01-11-github-actions-jobs-running-on-windows-latest-are-now-running-on-windows-server-2022/
There was a problem hiding this comment.
Ah nice, but do they support running linux docker containers within those containers? That was the problem we ran into last time.
…s of generated binaries
This PR enables the CLI to be packaged into standalone, executable binaries that can be used without installing NodeJS. Minor modifications were made to the CLI to accomodate the exectuables' virtual filesystem.
A new CI job runs the CLI tests against an executable binary to prevent regressions.
Production-ready binaries are created in the
cd-sourceworkflow. Binaries are built and stored in GitHub releases with the directory structure:linux-arm64/polywraplinux-x64/polywrapmacos-arm64/polywrapmacos-x64/polywrapwin-arm64/polywrapwin-x64/polywrapCloses #1875