You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now pre-built binaries are produced in release assets (including rcs), we want to create a script to make sure it actually works. test can cover:
(add a self-check commend)
daemon can be started
cli works
version is updated
can make a proof call
The text was updated successfully, but these errors were encountered:
What is the signal for knowing when a daemon is "started"? (This will be the objective of the test. Kindness please!)
Assumptions I'm making:
I will assume we're just going to ensure version reported on the CLI matches the current tag.
"CLI works" probably has a bunch of individual unit tests, I can pick a few just to establish the pattern here for more later.
for both i think we can just make sure lotus version is returning the right version.
@jennijuju Some clarification is needed around the "make a proof call" requirement. What would this script do that the above test does not do? What more would adding the lotus context provide for us? (I'm ultimately trying to understand what behavior we're attempting to protect with this check. It would seem the above test already incorporates the latest proof logic with 2k params and validates the proof.)
Now pre-built binaries are produced in release assets (including rcs), we want to create a script to make sure it actually works. test can cover:
(add a self-check commend)
The text was updated successfully, but these errors were encountered: