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

Create a script to validate the binary is runnable #6319

Open
3 of 4 tasks
jennijuju opened this issue May 24, 2021 · 3 comments
Open
3 of 4 tasks

Create a script to validate the binary is runnable #6319

jennijuju opened this issue May 24, 2021 · 3 comments
Assignees
Labels
area/ux Area: UX kind/enhancement Kind: Enhancement P2 P2: Should be resolved tribute

Comments

@jennijuju
Copy link
Member

jennijuju commented May 24, 2021

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
@jennijuju jennijuju added help wanted Extra attention is needed P2 P2: Should be resolved kind/enhancement Kind: Enhancement area/ux Area: UX labels May 24, 2021
@jennijuju jennijuju added tribute P2 P2: Should be resolved and removed P2 P2: Should be resolved help wanted Extra attention is needed labels Jul 21, 2021
@placer14 placer14 self-assigned this Sep 13, 2021
@placer14
Copy link
Contributor

Some scope clarification:

  • What is the signal for knowing when a daemon is "started"? (This will be the objective of the test. Kindness please!)
  • How do I make a proof call?

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.

@jennijuju
Copy link
Member Author

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.

How do I make a proof call?

id say

p1, err := sb.SealPreCommit1(context.TODO(), id, s.ticket, []abi.PieceInfo{s.pi})
can be a good example?

but @magik6k probably have a better answer to both q

@placer14
Copy link
Contributor

@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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ux Area: UX kind/enhancement Kind: Enhancement P2 P2: Should be resolved tribute
Projects
None yet
Development

No branches or pull requests

2 participants