refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx #6966

dckc · 2023-02-10T08:42:16Z

Description

Very literal port of agops-perf-smoketest.sh to JS using zx

Security Considerations

I hope this is a useful step toward OCap Discipline.

As a first step, ambient authority is localized to a folding region:

// #region ambient authority
import process from 'process';
import { $ } from 'zx';

const { env, argv: nodeArgv, exit } = process;
const echo = (...args) => console.log(...args);
// #endregion

Also, I find shell quoting rules frightening. Shellcheck and such can help, but we don't have that in CI. zx does much of that automatically:

Everything passed through ${...} will be automatically escaped and quoted.

We also rely on shell quoting mixed with make syntax more than I'm comfortable with in places like packages/cosmic-swingset/Makefile.

Scaling Considerations

This should allow us to gracefully push code down into modules and migrate it into things like the agoric CLI, or at least agops.

Documentation Considerations

This allows us to lean into our JS coding style, lint conventions, static typing, and such, though that's not without cost to folks more versed in shell scripting than JS.

Testing Considerations

Here's hoping this is also a step toward making such integration scripts run "lights out" in CI or the like.

cc @turadg @arirubinstein @michaelfig @erights @ivanlei @mhofman @gibson042 @warner

dckc · 2023-02-10T09:17:57Z

single-executable deployment?

further to #6455 / #6574 ... nexe seems to be a leading tool for packaging node apps as a single executable.

I tried it and it worked:

~/projects/agoric-sdk/packages/agoric-cli$ yarn nexe test/agops-perf-smoketest.js --remote "$NEXE_REMOTE"
yarn run v1.22.19
$ /home/connolly/projects/agoric-sdk/node_modules/.bin/nexe test/agops-perf-smoketest.js --remote https://github.com/urbdyn/nexe_builds/releases/download/0.2.0/
ℹ nexe 4.0.0-rc.2
✔ Downloading...100%
✔ Compiling result
✔ Entry: 'test/agops-perf-smoketest.js' written to: agops-perf-smoketest
✔ Finished in 3.075s
Done in 3.40s.

~/projects/agoric-sdk/packages/agoric-cli$ ./agops-perf-smoketest 
AGORIC_NET env not set

e.g. AGORIC_NET=ollinet (or export to save typing it each time)
...

Packaging seems pretty reasonable:

~/projects/agoric-sdk/packages/agoric-cli$ ls -lsh ./agops-perf-smoketest 
79M -rwxrwxr-x 1 connolly connolly 79M Feb 10 03:07 ./agops-perf-smoketest

~/projects/agoric-sdk/packages/agoric-cli$ ldd ./agops-perf-smoketest 
        linux-vdso.so.1 (0x00007ffea77ec000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f10eca23000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f10ec7f9000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10ec712000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f10ec6f2000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f10ec6ed000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10ec4c3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f10eca3c000)

Native Modules: no free lunch

In order to use native modules, the native binaries must be shipped alongside the binary generated by nexe.

so life looks complicated for sqlite3 and such. sad trombone

And of course, in our golang/js integration, nodejs is linked as a library. There isn't really a .js entrypoint. #5287 to the rescue?

prep, bumps in the road

rough notes...

nexe/nexe#1031 (comment)

nvm install 16  # got me 16.9
nvm use 16
npm install -g yarn
yarn add --dev nexe

NEXE_REMOTE="https://github.com/urbdyn/nexe_builds/releases/download/0.2.0/"
yarn nexe test/agops-perf-smoketest.js --remote "$NEXE_REMOTE"

linux-x64-16.19.0
https://github.com/urbdyn/nexe_builds/releases

supply chain risks... build it ourselves...

dckc · 2023-02-10T09:20:33Z

zx doesn't support node 14

at least not the current version:

error zx@7.1.1: The engine "node" is incompatible with this module. Expected version ">= 16.0.0". Got "14.21.2"

-- https://github.com/Agoric/agoric-sdk/actions/runs/4142272715/jobs/7162749774#step:3:206

turadg

Node 14

Active support ended Oct 2021 and Security support ends 30 Apr 2023, a couple months. I think it's fine to couple adopting of zx with dropping Node 14.

However, I don't think we necessarily need to include zx as a devDependency if we use it as a shell env. The smoketest scripts don't run in CI and even if they were to we might want to just include zx from the Ubuntu install.

Here's hoping this is also a step toward making such integration scripts run "lights out" in CI or the like.

IMO this script isn't a good candidate for that. It's meant to be didactic and used for local debugging. If we want a CI test integrating agops I think that's worth writing fresh.

turadg · 2023-02-10T14:46:04Z

packages/agoric-cli/test/agops-perf-smoketest.js

@@ -0,0 +1,53 @@
+#!/usr/bin/env node


Why not #!/usr/bin/env zx? That would save many imports. I suppose you'd prefer those imports for being explicit about ambient authority. What is the risk that you're trying to mitigate by that?

OCap discipline isn't just about mitigating risk. It's about testability, auditability, modularity, reusability. In sum: good engineering.

Engineering is all about trade-offs. One not in your list is velocity.

I find it's good for velocity too, especially if done always from the beginning so you don't have to retrofit later.

turadg · 2023-02-10T14:49:59Z

packages/agoric-cli/test/agops-perf-smoketest.js

+// NOTE: USDC_axl = ibc/usdt1234
+// perf test wantMinted
+let OFFER = await $`mktemp -t agops.XXX`;
+await $`bin/agops psm swap --wantMinted 0.01 --feePct 0.01 --pair IST.USDC_axl >|${OFFER}`;


I'm gung ho about zx but there's a downside to JS syntax for for these smoketest scripts. I tend to run them interactively by copying lines over to my shell. This makes that harder to do.

For this script, I'm more inclined to keep the shell commands but place them into a Markdown file that zx would run. I want to make the prose primary and the commands incidental to executing the prose.

Even with that we'd get easier refactoring like extracting all the arg setup and diagnostics to a support function.

this script isn't a good candidate for that [=lights out].

got it.

I tend to run them interactively by copying lines over to my shell.

I hope to avoid that. Very much not my style.

If we want a CI test integrating agops I think that's worth writing fresh.

This script does represent a product scenario that's worth lots of testing. The extent to which any automated test shares code with the copy-to-my-shell script, I don't have strong feelings.

I hope to avoid that. Very much not my style.

Sounds worth a conversion to find a mutually agreeable design compatible with our workflows.

dckc · 2023-03-31T00:17:37Z

This experiment has run its course.

dckc added 5 commits February 10, 2023 02:12

build: zx devDependency for testing

8240433

build: lock packages with zx

0ecad4d

refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx

d4ecfae

fixup! refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx

550bbd5

fixup! refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx

c3feae2

turadg reviewed Feb 10, 2023

View reviewed changes

dckc closed this Mar 31, 2023

turadg mentioned this pull request Aug 2, 2023

convert Chain Upgrade Tester to use JS instead of Bash #8137

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx #6966

refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx #6966

dckc commented Feb 10, 2023 •

edited

Loading

dckc commented Feb 10, 2023 •

edited

Loading

dckc commented Feb 10, 2023

turadg left a comment

turadg Feb 10, 2023

dckc Feb 10, 2023

turadg Feb 10, 2023

dckc Feb 10, 2023

turadg Feb 10, 2023

dckc Feb 10, 2023

turadg Feb 10, 2023

dckc commented Mar 31, 2023

refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx #6966

refactor(agoric-cli): sh->js port of agops-perf-smoketest with zx #6966

Conversation

dckc commented Feb 10, 2023 • edited Loading

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

dckc commented Feb 10, 2023 • edited Loading

single-executable deployment?

Native Modules: no free lunch

prep, bumps in the road

dckc commented Feb 10, 2023

zx doesn't support node 14

turadg left a comment

Choose a reason for hiding this comment

turadg Feb 10, 2023

Choose a reason for hiding this comment

dckc Feb 10, 2023

Choose a reason for hiding this comment

turadg Feb 10, 2023

Choose a reason for hiding this comment

dckc Feb 10, 2023

Choose a reason for hiding this comment

turadg Feb 10, 2023

Choose a reason for hiding this comment

dckc Feb 10, 2023

Choose a reason for hiding this comment

turadg Feb 10, 2023

Choose a reason for hiding this comment

dckc commented Mar 31, 2023

dckc commented Feb 10, 2023 •

edited

Loading

dckc commented Feb 10, 2023 •

edited

Loading