-
Notifications
You must be signed in to change notification settings - Fork 119
chore: test the core library in nightly run
#5317
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
Conversation
This reverts commit 63bba0b.
388af6e to
572eca0
Compare
| - name: Set up `mops` cache | ||
| run: | | ||
| npx mops --version | ||
| npx ${DFX_MOC_PATH} --version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This runs moc and primes the .mops cache.
|
|
||
| motoko-core-tests: | ||
| needs: systems-go-tests | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cheapest...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we avoid installing dfx? I don't think we need it: https://github.com/dfinity/motoko/actions/runs/16174606575/job/45656733947#step:7:122
Actually it shouldn't install at all: https://github.com/dfinity/motoko-core/blob/main/.github/actions/setup/action.yml#L13
I opened dfinity/motoko-core#345.
| - name: Fixup `mops` cache | ||
| run: | | ||
| ln -sf /nix/store/*-moc/bin/moc $(cat .mops/moc-*) | ||
| npx ${DFX_MOC_PATH} --version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above suggestion:
| npx ${DFX_MOC_PATH} --version | |
| ${DFX_MOC_PATH} --version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, turns out I need npx:
/home/runner/work/_temp/97eb8911-f1e2-402c-9905-dd49540368c6.sh: line 2: moc-wrapper: command not found
Error: Process completed with exit code 127.
It seems like we could do this! |
Co-authored-by: Ryan Vandersmith <[email protected]>
Co-authored-by: Ryan Vandersmith <[email protected]>
| run: | | ||
| nix build .#moc --print-out-paths | ||
| - name: Save the `test-blueprint` action | ||
| run: cp -r ./.github/actions/test-blueprint .. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not super clear to me: why do we need to copy the blueprint somewhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the checkout of motoko-core zeroes out the previous checkout. Explained: #5317 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oooh, I see -- can you please add a comment here as well about it so we don't break it some time later when we refactor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
core in nightly runcore library in nightly run
alexandru-uta
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; the only thing I think would help some more is adding the comment in the yml saying explicitly why we copy the blueprint in and out.

dfinity/mops#300 is merged and released. dfinity/motoko-core#344 adopted it.
Note: I wouldn't have problems to leave this new step in this workflow, but separating it out into a second one should also be doable with a little bit of duplication. We can iterate from this point.
Note: Without the
mops64-bit fix the tests failed, so the rainy-day path is well-tested!