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

Add some versioning & tags relating to upstream releases #124

Open
nuke-web3 opened this issue Jun 28, 2024 · 5 comments
Open

Add some versioning & tags relating to upstream releases #124

nuke-web3 opened this issue Jun 28, 2024 · 5 comments
Labels
devex enhancement New feature or request

Comments

@nuke-web3
Copy link
Contributor

It's not clear what version of this template is compatible with https://github.com/risc0/risc0/ and/or https://github.com/risc0/risc0-ethereum/ releases.

I can guess based on the PRs and commit history & cargo files... but that is really not great UX

@nuke-web3 nuke-web3 added enhancement New feature or request help wanted Extra attention is needed labels Jun 28, 2024
@nuke-web3
Copy link
Contributor Author

nuke-web3 commented Jun 28, 2024

from #110 it seems 27eba00 is a candidate to tag v1.0.0 ?

also perhaps missed in that PR:

branch = v1.0.0-rc.6

https://stackoverflow.com/questions/1777854/how-can-i-specify-a-branch-tag-when-adding-a-git-submodule suggests perhaps branch should be omitted and manually update the submodules correctly before the tag is set at a commit that locks in those submodule upstream commits used?

Update: diff to the "right" branch might be a blocker: risc0/risc0-ethereum@v1.0.0-rc.6...release-1.0

@nategraf nategraf self-assigned this Jul 1, 2024
@nuke-web3
Copy link
Contributor Author

nuke-web3 commented Jul 2, 2024

Error: failed to fill whole bufferthread main' panicked at risc0/r0vm/src/lib.rs:192:18:called Result::unwrap()on anErr value: incompatible client version: 1.1.0-alpha.1, server version: 1.0.1

This comes from using an incompatible submodule in forge test. This is a really bad error message to inform that is the case IMHO. The error is also not rendered with \n in stdout, so I needed to manually parse it to find that error in a single line of 1000s of chars 🙈

This .gitsubmodule worked for me, being careful here that I MUST match my Cargo.toml deps on all versions to match as well.

[submodule "remote-network-prover/lib/risc0-ethereum"]
	path = remote-network-prover/lib/risc0-ethereum
	url = https://github.com/risc0/risc0-ethereum
	branch = release-1.0
[submodule "remote-network-prover/lib/forge-std"]
	path = remote-network-prover/lib/forge-std
	url = https://github.com/foundry-rs/forge-std
[submodule "remote-network-prover/lib/openzeppelin-contracts"]
	path = remote-network-prover/lib/openzeppelin-contracts
	url = https://github.com/OpenZeppelin/openzeppelin-contracts

I then get another error after a long time waiting on some proofs to run for a not so easy to spot in a single line of 1000s of chars -> I need docker:

2024-07-02T03:21:59.418511Z ERROR cheatcodes: non-empty stderr input=["cargo", "run", "--manifest-path", "lib/risc0-ethereum/ffi/Cargo.toml", "--bin", "risc0-forge-ffi", "-q", "prove", "/home/nuke/git/r0/workshops/test/remote-network-prover/target/riscv-guest/riscv32im-risc0-zkvm-elf/release/is-even", "0x0000000000000000000000000000000000000000000000000000000000bc614e"] stderr="Error: Please install docker first.

Ideally if we know we need docker, we check that before doing any more work & fail fast with a message.

Finally I still error with

2024-07-02T03:30:57.235374Z ERROR cheatcodes: non-empty stderr input=["cargo", "run", "--manifest-path", "lib/risc0-ethereum/ffi/Cargo.toml", "--bin", "risc0-forge-ffi", "-q", "prove", "/home/nuke/git/r0/workshops/test/remote-network-prover/target/riscv-guest/riscv32im-risc0-zkvm-elf/release/is-even", "0x0000000000000000000000000000000000000000000000000000000000bc614e"] stderr="Error: docker returned failure exit code: Some(125)

Note that I am trying to alias docker to podman with ln -s /usr/bin/podman /usr/bin/docker that might be to blame... I would love to have podman as a first class option or other alts to hard-coded docker as the only container option we support.

UPDATE: tried with docker too, so likely there is some issue on my end. Using foundry template from 37d4ce7 with the edited submodule listed above.

https://stackoverflow.com/a/35410993 suggests that there is something happening in the container or the command itself at fault? This is not great UX 🙈

Subproject commit
openzeppelin-contracts ccc110360f1028143e137258d12a0891f17df3a4
forge-std 37d4ce7f927b2c018538378799258373fbbba4c8
risc0-ethereum ebec385cc526adb9279c1af55d699c645ca6d694

RISC0_DEV_MODE=true forge test -vvv passes test (with errors warning about dev mode) when using risc0-ethereum ebec385cc526adb9279c1af55d699c645ca6d694 - but same issues as above with with a real proof.

@nuke-web3
Copy link
Contributor Author

nuke-web3 commented Jul 2, 2024

manually checking out the v1.0.0-rc.6 tag mentioned in the existing (but not working! .gitmodule as it must be a branch!) and committing this

non-empty stderr input=["cargo", "run", "--manifest-path", "lib/risc0-ethereum/ffi/Cargo.toml", "--bin", "risc0-forge-ffi", "-q", "prove", "/home/nuke/git/r0/workshops/test/remote-network-prover/target/riscv-guest/riscv32im-risc0-zkvm-elf/release/is-even", "0x0000000000000000000000000000000000000000000000000000000000000000"] stderr="Error: failed to fill whole bufferthread 'main' panicked at risc0/r0vm/src/lib.rs:192:18:\ncalled Result::unwrap()on anErr value: incompatible client version: 1.0.0-rc.6, server version: 1.0.1\n\nStack backtrace:

So again in version hell 😮‍💨 why are patch versions not good enough to work here? Semver not respected?

resolved in #126

nuke-web3 added a commit that referenced this issue Jul 2, 2024
https://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-git-branch-to-a-different-commit states we cannot use tags, so this branch = tag is broken.

Instead of updating here, we will manage commits for sub-modules manually and locked into the tags/releases for known working versions (in #124 )
nategraf pushed a commit that referenced this issue Jul 2, 2024
https://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-git-branch-to-a-different-commit states we cannot use tags, so this branch = tag is broken.

Instead of updating here, we will manage commits for sub-modules manually and locked into the tags/releases for known working versions (in #124 )
@nategraf
Copy link
Contributor

nategraf commented Jul 2, 2024

So again in version hell 😮‍💨 why are patch versions not good enough to work here? Semver not respected?

1.0.0-rc.6 is not compatible with 1.0.0 or 1.0.1 by the rules of semver. https://semver.org/#spec-item-9

@nuke-web3
Copy link
Contributor Author

TIL more about semver 🙇

Putting here for more motivation on better versions for the many moving parts in risc0 ethereum risc0/risc0-ethereum#137

Also noticing in examples many will want to use that we have cargo.io patches in use - what is the versioning and upgrade story on those? Like:

https://github.com/risc0/risc0-ethereum/blob/604be7888bba8b804236f41c241750f98cac820b/examples/erc20/methods/guest/Cargo.toml#L17-L21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devex enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants