refactor: standalone basic_solana for ICP Ninja#249
Conversation
basic_solanabasic_solana for ICP Ninja
4c4a4a9 to
42aea94
Compare
42aea94 to
e59b66b
Compare
.github/workflows/ci.yml
Outdated
|
|
||
| - name: 'Check ninja Cargo.toml' | ||
| run: python3 .github/scripts/check_ninja_cargo_toml.py | ||
| # TODO DEFI-2462: Re-enable once `sol_rpc_client` and `sol_rpc_types` crates using `ic-cdk` v0.18.6 are published |
There was a problem hiding this comment.
understanding question: to make it easier to review in the future. Wouldn't it be possible to let the source code of the example as is and comment out the CI part that builds the example? So that basically just a couple of lines are to be reviewed instead of currently 700 (I know it's probably just a copy from the symlink, but the problem is that the reviewer is supposed to verify the diff, which is annoying).
There was a problem hiding this comment.
The problem is that then in the meantime the ICP Ninja deployment wouldn't work anymore... Not just in the CI but generally the links to deploy to ICP Ninja would link to something that doesn't compile. I completely agree that this is very annoying and honestly I'm not sure doing this circus everytime we have a breaking change is very sustainable (especially given the tendency of ic-cdk to have breaking changes).
Maybe we should consider making the examples use the latest published release altogether? We could also have a CI pipeline job that checks that we are using the latest published version of our crates to ensure the examples don't fall behind.
WDYT?
There was a problem hiding this comment.
The problem is that then in the meantime the ICP Ninja deployment wouldn't work anymore... Not just in the CI but generally the links to deploy to ICP Ninja would link to something that doesn't compile.
Good point, that wouldn't be nice.
Maybe we should consider making the examples use the latest published release altogether?
yes, I think that's a good suggestion, particularly since now that we launch the API should be much more stable.
We could also have a CI pipeline job that checks that we are using the latest published version of our crates to ensure the examples don't fall behind.
I think here we should be able to just re-use dependabot, no? I think we could just tell dependabot to update sol_rpc_client and sol_rpc_types only (to limit also the amount of noise that the other updates generates). WDYT?
There was a problem hiding this comment.
Sounds good! I've refactored things so that the basic_solana example is now completely standalone (i.e. has no path dependencies in Cargo.toml and depends only on published crates).
I've also made the CI job a bit more robust to test the local and ninja deployments each with both macOS and Ubuntu. I even uncovered a small mistake in examples/basic_solana/local/dfx.json in the process.
Note that the diff is huge, but it's almost entirely the new Cargo.lock for basic_solana.
I think here we should be able to just re-use dependabot, no? I think we could just tell dependabot to update sol_rpc_client and sol_rpc_types only (to limit also the amount of noise that the other updates generates). WDYT?
That's a very good idea! I'll take care of that in a separate PR but I agree that at this point dependabot has become more or less noise...
.github/workflows/ci.yml
Outdated
|
|
||
| - name: 'Check ninja Cargo.toml' | ||
| run: python3 .github/scripts/check_ninja_cargo_toml.py | ||
| # TODO DEFI-2462: Re-enable once `sol_rpc_client` and `sol_rpc_types` crates using `ic-cdk` v0.18.6 are published |
There was a problem hiding this comment.
The problem is that then in the meantime the ICP Ninja deployment wouldn't work anymore... Not just in the CI but generally the links to deploy to ICP Ninja would link to something that doesn't compile.
Good point, that wouldn't be nice.
Maybe we should consider making the examples use the latest published release altogether?
yes, I think that's a good suggestion, particularly since now that we launch the API should be much more stable.
We could also have a CI pipeline job that checks that we are using the latest published version of our crates to ensure the examples don't fall behind.
I think here we should be able to just re-use dependabot, no? I think we could just tell dependabot to update sol_rpc_client and sol_rpc_types only (to limit also the amount of noise that the other updates generates). WDYT?
| "init_arg": "( record { solana_network = opt variant { Devnet }; ed25519_key_name = opt variant { MainnetTestKey1 }; sol_rpc_canister_id = opt principal \"tghme-zyaaa-aaaar-qarca-cai\" } )" | ||
| }, | ||
| "sol_rpc": { | ||
| "candid": "https://github.com/dfinity/sol-rpc-canister/releases/download/v1.0.0/sol_rpc_canister.did", |
There was a problem hiding this comment.
For another PR, but the candid file should probably be updated with the latest release.
There was a problem hiding this comment.
Good catch! I'll update it in another PR, thanks for pointing it out!
| "ic": "tghme-zyaaa-aaaar-qarca-cai" | ||
| } | ||
| }, | ||
| "wasm": "https://github.com/dfinity/sol-rpc-canister/releases/download/v1.0.0/sol_rpc_canister.wasm.gz", |
In #249, the `basic_solana` example was refactored to be standalone and was thus removed from the repository's top-level Cargo workspace. This PR updates `release-plz.toml` accordingly by removing the outdated override to ignore the `basic_solana` crate to fix the `Release` job (see an example run with an error [here](https://github.com/dfinity/sol-rpc-canister/actions/runs/20909693682)).
(DEFI-2462) Refactor the
basic_solanaexample to be fully standalone, using only published crate versions. This allows the example to be imported directly into ICP Ninja without requiring forks due to breaking changes insol_rpc_typesorsol_rpc_client(as was done in #197).The CI pipeline is updated with more robust testing for both local and ICP Ninja deployments of
basic_solanaviadfx, covering macOS and Linux.