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

test: new job to test the XS worker #1649

Merged
merged 6 commits into from
Oct 1, 2020
Merged

test: new job to test the XS worker #1649

merged 6 commits into from
Oct 1, 2020

Conversation

warner
Copy link
Member

@warner warner commented Aug 31, 2020

Enhance the test-swingset GitHub Actions CI job to also build and test the new xs-vat-worker executable.

refs #1299

@warner warner added the SwingSet package: SwingSet label Aug 31, 2020
@warner warner marked this pull request as draft August 31, 2020 18:52
@warner warner force-pushed the 1299-xs-worker-ci branch 2 times, most recently from 8893b2e to f832a4e Compare September 1, 2020 01:58
@warner warner marked this pull request as ready for review September 1, 2020 02:13
@warner
Copy link
Member Author

warner commented Sep 1, 2020

@michaelfig please take a look at the github workflow file and check that my changes aren't going to mess up / get messed up by the cache operations.. I don't really understand when the cache is read/written to. It'd be nice to cache the XS toolkit (the part built by make $(TOOLS)/mcconfig), which is a function of the git submodule we check out (plus the CI host's compiler/etc), but shouldn't depend upon any agoric-sdk source code. But it's not critical to cache it.. rebuilding that stuff takes about two minutes.

But the xs-vat-worker executable should probably not be cached (or at least we need to be careful to rebuild it at the right times). It's a function of a handful of swingset sources, plus the compartmap.json (which has similar dependencies). I think building xs-vat-worker is pretty quick.

@dckc please check what I did to your Makefile (xs-lin.mk) to make the compile steps be more visible. I deleted compartmap.json and added it to .gitignore because it appears to be a generated file, does that sound right? I moved the git-submodule stuff up higher in the process (to the test-all-packages.yml workflow step that does the original git-clone). And the debian/ubuntu apt package name that contains gio.h was different on all the systems I looked at (libglib not libgio), so I updated that too.

.PHONY: all

all:
$(MAKE) -f xs-lin.mk build
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why $(MAKE) in a subprocess rather than just make all depend on build?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted a place to emit distinctive echo lines just before each step ran (because they were failing as I figured things out); using the normal make dependencies didn't make it clear when the stages were happening. That said, now that it works, I don't strictly need it anymore.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no strong feelings.

install-gio:
sudo apt-get -y update && sudo apt-get -y install libgio2.0-dev
sudo apt-get -y update && sudo apt-get -y install libglib2.0-dev
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised that suffices... I think it won't if/when we use sockets from within XS. But I'm OK with it for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can tell (https://packages.ubuntu.com/search?keywords=libgio&searchon=names&suite=all&section=all) libgio2.0-dev isn't actually a package. I think libgio and libglib header/.a files are both included in the libglib2.0-dev package.

Copy link
Member

@michaelfig michaelfig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, modulo cleaning up the Github action a bit. It really needs to be meticulously tidied for understandability, since there is no such thing as macros in that yaml file. But you did discern the right things to change.

if: steps.built.outputs.cache-hit != 'true'
- name: yarn install
run: yarn install
if: steps.built.outputs.cache-hit != 'true'
- name: install XS dependencies
working-directory: ./packages/xs-vat-worker
run: yarn install:xs-lin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move this clause below the # END-RESTORE-BOILERPLATE.

- name: yarn build
run: yarn build
if: steps.built.outputs.cache-hit != 'true'
- name: yarn build-xs-worker
working-directory: ./packages/xs-vat-worker
run: yarn build:xs-lin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this one too. (You didn't change the boilerplate that all the tests use except for the with: submodules: 'true'.)

@dckc
Copy link
Member

dckc commented Sep 1, 2020

@dckc please check what I did to your Makefile (xs-lin.mk) to make the compile steps be more visible.

Maintainability edits look fine (though I haven't tested them or anything like that). But...

I deleted compartmap.json and added it to .gitignore because it appears to be a generated file, does that sound right?

As I said in our earlier discussion, I'm hesitant to rely on the tool that generates it; have you reviewed tools/findmods.js carefully? I didn't have in mind production-quality lights-out operation when I wrote it; I had in mind that a developer would manually check the results, partly by doing a git diff. In particular, I wouldn't be surprised if it fails on unexpected inputs by silently producing an empty or nonsensical output.

I also wanted to check for compatibility with @kriskowal 's endo work by using typescript; I did that and discovered that there is indeed an arbitrary difference in our designs.

https://github.com/dckc/agoric-sdk/commits/endo-types

I had in mind to use #57 to represent the work to finish the work on findmod.js, ideally by letting endo subsume it.

@dckc
Copy link
Member

dckc commented Sep 1, 2020

@dckc please check what I did to your Makefile (xs-lin.mk) to make the compile steps be more visible.

I looked over the ci logs and they are as I would expect. Rather satisfying, in fact.

https://github.com/Agoric/agoric-sdk/runs/1054099878?check_suite_focus=true

I somewhat regret that the burden of building this ci step fell to you instead of me, but I suppose it serves as a form of code-review of the stuff I did.

The C code in our branch of the moddable SDK has some debugging diagnostics that I think I originally inherited some from prototyping work that you did; I suppose they should be hidden by default before too much longer but they're OK for now?

lin_xs_cli: loading top-level main.js
 lin_xs_cli: loaded
lin_xs_cli: invoking main(argv)
 lin_xs_cli: main(): entering event loop

@dckc
Copy link
Member

dckc commented Sep 1, 2020

oh... the .bin path in clean is left-over from earlier; I suppose it's harmless, but while we're doing maintainability edits, maybe get rid of it?

clean:
	rm -rf build $(NODE_MODULES)/.bin/xs-vat-worker

@warner warner force-pushed the 1299-xs-worker-ci branch 5 times, most recently from 64306a8 to 0396ced Compare September 21, 2020 21:26
@warner warner changed the base branch from master to 1775-protocol-fix September 21, 2020 21:26
@warner warner force-pushed the 1775-protocol-fix branch 2 times, most recently from a077819 to 38c63fb Compare October 1, 2020 20:20
Base automatically changed from 1775-protocol-fix to master October 1, 2020 20:33
This changes the "test swingset" CI job to additionally build the XS
toolkit (written in C), and then use that toolkit to compile the
`xs-vat-worker` program. The SwingSet unit tests will then exercise this
program (they skip the test unless the program is available).

To make the results more visible, another small step was added to run just
the one unit test that exercises `xs-vat-worker`.

The `git clone` steps were changed to include submodules, since the
xs-vat-worker package uses a git submodule to fetch our modified version of
the XS source tree.

refs #1299
The original name came from the XS build tool convention, but required
annoying `-f` flags every time you use it, and we're only ever building for
linux/unix here.
@warner warner merged commit 7ff75e1 into master Oct 1, 2020
@warner warner deleted the 1299-xs-worker-ci branch October 1, 2020 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SwingSet package: SwingSet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants