Using latest dfx 0.15.2
dfx nns - deploys old dapp that can’t launch SNS
dfx sns - uses old sns.yaml
Trying to build sns standalone as instructed by docs results in error:
bazel build //rs/sns/cli:sns
ERROR: --experimental_remote_cache_async :: Unrecognized option: --experimental_remote_cache_async
ERROR: Failed to init TLS infrastructure: JDK provider does not support ALPN protocol
https://github.com/dfinity/sns-testing
sns-testing using a docker works well and the tokenomics analyzer runs without issues.
Testing launches works also.
The problem comes when you try to deploy your app locally, make proposal functions, and test upgrades.
I would prefer not to use tooling made out of bash scripts, linux commands, and text candid. I’ve avoided using these successfully for over a year and I am very happy with that.
I want to make my own proposal/upgrade tools.
and trying to use local dfx tools with the docker running dfx results in error:
The lookup path ([726571756573745F737461747573, 2EF208A2EE93ACFD76BCE8C0B27381522D86B0F3799385035383DF3737ABD087, 737461747573]) is unknown in the certificate.
Trying to put the whole sns-testing repo inside a dev container also results in an error.
Any ideas how to use the dfx tool from outside the repo with the replica running inside docker?
Or when are we getting the dfx nns and dfx sns updated? That would make things so much easier.
Thanks for reporting this. We would need a bit more info to be able to help.
First of all, could you summarize on a high level what your use case is? In particular, do you need some recently added DFX features that would require dfx 0.15.2, or would an older DFX version still cover your use case?
and trying to use local dfx tools with the docker running dfx results in error: The lookup path ... is unknown in the certificate.
Which exact command did you run when you observed this issue?
Trying to put the whole sns-testing repo inside a dev container also results in an error.
sns-testing already has an official docker image called ghcr.io/dfinity/sns-testing:main, please carefully follow these instructions and let me know whether they work for you.
Any ideas how to use the dfx tool from outside the repo with the replica running inside docker?
This is currently not guaranteed to work with sns-testing, unless you find a suitable configuration for your particular host system. Instead, the recommended approach is to use the DFX tool from the container to interact with the sns-testing deployment. This still allows to customize the container and image as per your dapp’s requirements.
For context: The main reason we provide the ghcr.io/dfinity/sns-testing:main image is be be able to isolate the sns-testing environment from whatever host system there may be, and even then it is a hard problem to ensure that the image works the same on all platforms.
I would prefer not to use tooling made out of bash scripts, linux commands, and text candid. I’ve avoided using these successfully for over a year and I am very happy with that.
I want to make my own proposal/upgrade tools.
I completely agree with this view, thanks for summarizing it. The point of sns-testing is not to create a new product on top of DFX, but show case how a some characteristic scenarios can be implemented end-to-end. That being said, we strive to enable developers such as yourself to effectively use the official tooling.
Also, could you please clarify which instructions recommended that you build via bazel build //rs/sns/cli:sns? Asking because the sns-testing instruction don’t require (and aren’t refering to) bazel at all.
Yes these work for me with the basic scenario. Like you have pointed out, the scope of the repo is not to develop on top of it, but test the decentralization.
Some problems when I try to change the config. According to this I am assuming placing sns_init.yaml next to the example_sns_init.yaml will use my configuration, but that doesn’t happen. It still launches “Rock Out”. I’ve got inside the docker shell and sns_init.yaml is not my config. I’ll replace it somehow and figure it out.
Ideally devs and people who are trying to replicate, test functions and verify things, should be able to do something like this:
dfx start --clean
dfx nns install
dfx sns deploy
And now we have an SNS we can locally test and experiment with.
Here are the steps that got me to test with custom sns_init.yaml. There can be some env variable or another trick that makes the ‘run_basic_scenario.sh’ to work with your custom config, but I don’t know what it is.
Get the new canister id and place it in your sns_init.yaml - dapp_canisters
Get your identity dfx identity get-principal and place it in - fallback_controller_principals
Put the sns_init.yaml inside container cp /dapp/sns_init.yaml /home/sns
If there are errors and you fix them, then it may say it can’t launch more than one SNS, delete container and start over. Make sure you replace the new identity and canister_id.
I didn’t change anything really. The instructions I’ve put up there are what I used.
Also - since I had ubuntu I could just copy the sns binary and use it outside docker to make my proposal. And I didn’t have to solve the bazel compilation error having problems with JDK.
I guess in few weeks these tricks will be irrelevant, because the tooling with get updated.
