chore: test the core library in nightly run#5317
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.
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.
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 caffeinelabs/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.
See above suggestion:
| npx ${DFX_MOC_PATH} --version | |
| ${DFX_MOC_PATH} --version |
There was a problem hiding this comment.
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 <ryan.vandersmith@dfinity.org>
Co-authored-by: Ryan Vandersmith <ryan.vandersmith@dfinity.org>
| 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.
not super clear to me: why do we need to copy the blueprint somewhere else?
There was a problem hiding this comment.
Because the checkout of motoko-core zeroes out the previous checkout. Explained: #5317 (comment)
There was a problem hiding this comment.
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?
core in nightly runcore library in nightly run
alexandru-uta
left a comment
There was a problem hiding this comment.
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.

caffeinelabs/mops#300 is merged and released. caffeinelabs/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!