Skip to content

Commit

Permalink
:Merge branch 'devDeploy' into add-alex-staging
Browse files Browse the repository at this point in the history
  • Loading branch information
@tiusty
tiusty committed Aug 27, 2023
2 parents 5dddb17 + 58e01b7 commit 95ef7c9
Show file tree
Hide file tree
Showing 46 changed files with 4,786 additions and 3,938 deletions.
451 changes: 233 additions & 218 deletions README.md
View file

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion dfx.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@
"local": "br5f7-7uaaa-aaaaa-qaaca-cai",
"development": "tsmol-tqaaa-aaaag-abt2a-cai",
"testing": "t6nyb-faaaa-aaaal-qcbaa-cai",
"alexStaging": "yqn2i-hyaaa-aaaap-qbmiq-cai"
"alexStaging": "yqn2i-hyaaa-aaaap-qbmiq-cai"
}
}
},
Expand Down
16 changes: 16 additions & 0 deletions notes/CanisterCyclesNotes.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Cycles for Mainnet Canisters
Fund wallet with cycles (from ICP): https://medium.com/dfinity/internet-computer-basics-part-3-funding-a-cycles-wallet-a724efebd111

## Top up cycles:
dfx identity --network=ic get-wallet
dfx wallet --network ic balance
dfx canister --network ic status PersonalWebSpace_backend
dfx canister --network ic status PersonalWebSpace_frontend
dfx canister --network ic --wallet 3v5vy-2aaaa-aaaai-aapla-cai deposit-cycles 3000000000000 PersonalWebSpace_backend
dfx canister --network ic --wallet 3v5vy-2aaaa-aaaai-aapla-cai deposit-cycles 300000000000 PersonalWebSpace_frontend

## Top up history
2023-02-16:
topped up 7T cycles each for new balances:
PersonalWebSpace_backend Balance: 10_896_387_427_956 Cycles (2023-03-06: 10.895, 2023-07-05: 10_882_246_216_265)
PersonalWebSpace_frontend Balance: 10_220_358_949_308 Cycles (2023-03-06: 10.079, 2023-07-05: 9_481_199_655_794)
0 DevelopmentNotes.md → notes/DevelopmentNotes.md
View file
File renamed without changes.
129 changes: 64 additions & 65 deletions NotesOnLocalDev.md → notes/NotesOnLocalDev.md
View file
Original file line number Diff line number Diff line change
@@ -1,65 +1,64 @@
There are three files where I added a comment like Local vs Mainnet Development
For the two UI files, those parts are responsible for the UI communicating with the local backend (IC replica running the canisters including the backend canister)

There might be issues with my setup as I'm running the Linux subsystem on Windows, so when I run npm run vite it gives me
Local: http://localhost:3000/
Network: http://172.30.141.44:3000/
but http://localhost:3000/ doesn't work for me
you could try uncommenting the block comment for the proxy in vite.config.ts (right under the comment with Local vs Mainnet Development) and see if that works for you

Currently http://172.29.55.198:3000/ from the hot reloading npm run vite is able to access the backend cansiter. The system seems to be able to call the replica and load rooms from the canisters. To get it to work you need to run npm run dev which starts the backend canister, the downside is that the hot relating links will call the deployed canisters from npm run dev which means that those pages are not hot reloading. But at least the calls work


Working with the UI spun up by npm run vite has the advantage that it supports hot reloading for changes made to the UI so one doesn't need to redeploy on every UI change.
that's not the case for the UI canister spun up with
dfx deploy --argument "(
principal\"$(dfx identity get-principal)\",
record {
logo = record {
logo_type = \"image/png\";
data = \"\";
};
name = \"PersonalWebSpace\";
symbol = \"PWS\";
maxLimit = 65535;
}
)"
after running that command you get sth like
Deployed canisters.
URLs:
Frontend canister via browser
PersonalWebSpace_frontend: http://127.0.0.1:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai
Backend canister via Candid interface:
PersonalWebSpace_backend: http://127.0.0.1:4943/?canisterId=r7inp-6aaaa-aaaaa-aaabq-cai&id=rrkah-fqaaa-aaaaa-aaaaq-cai
http://127.0.0.1:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai doesn't work properly for me either (calls to the backend are also rejected) but http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai actually works (which usually should be the same as far as I know but it might be that my Linux subsystem setup messes this up)
thus, http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai can also call the backend successfully
creating a space still fails though as the local IC replica doesn't have the protocol canister running (which our backend uses). We could comment out the call to the protocol canister from the backend canister though (see comment with Local vs Mainnet Development in main.mo).
After commenting out the protocol call, the call to create a space is successful. Note that the preview shown in the section My Spaces points to the mainnet UI canister (i.e. doesn't show the local canisters). To see the local canister go to http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai#/space/0 (might need to refresh to work).
for accessing routes with this, one can use e.g.
http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai#/testroom
the disadvantage here is that there isn't any hot reloading, so after every change one has to redeploy the canisters with
dfx deploy --argument "(
principal\"$(dfx identity get-principal)\",
record {
logo = record {
logo_type = \"image/png\";
data = \"\";
};
name = \"PersonalWebSpace\";
symbol = \"PWS\";
maxLimit = 65535;
}
)"

Running Bebb Protocol locally:
This project's dfx.json specifies Bebb Protocol as a remote canister (i.e. can be used by project's canisters locally but isn't built as it relies on the remote canister being deployed to the local replica from another project). It's canister bebbprotocol. The files for the integration (wasm, did, js, ts) need to be copied over to the integrations/BebbProtocol folder manually if changed.
Clone Bebb Protocol's repo: https://github.com/Bebb-Protocol-and-Apps/BebbProtocol
And use the latest version (e.g. 0.0.4 as of 2023-07)
Go to OIM's codebase (where the file you're reading is in)
Start a local replica in this project (OIM)
Deploy this project's canisters, PersonalWebSpace_backend and PersonalWebSpace_frontend, see deploy command in README (after these steps the following canister ids should be assigned: PersonalWebSpace_backend canister id: rrkah-fqaaa-aaaaa-aaaaq-cai; PersonalWebSpace_frontend canister id: ryjl3-tyaaa-aaaaa-aaaba-cai)
Go to the folder with Bebb Protocol's latest version and run dfx deploy there (this creates the local Bebb Protocol canister on the local replica started earlier which is thus the same replica this project's canisters are running on)
Make sure the local canister id for the deployed Bebb Protocol canister is br5f7-7uaaa-aaaaa-qaaca-cai (required by this project to make the calls on the local replica)
This project's canisters should now successfully call the locally deployed Bebb Protocol canister (i.e. all functionality works, same as on mainnet)
Test via npm run vite

There are three files where I added a comment like Local vs Mainnet Development
For the two UI files, those parts are responsible for the UI communicating with the local backend (IC replica running the canisters including the backend canister)

There might be issues with my setup as I'm running the Linux subsystem on Windows, so when I run npm run vite it gives me
Local: http://localhost:3000/
Network: http://172.30.141.44:3000/
but http://localhost:3000/ doesn't work for me
you could try uncommenting the block comment for the proxy in vite.config.ts (right under the comment with Local vs Mainnet Development) and see if that works for you

Currently http://172.29.55.198:3000/ from the hot reloading npm run vite is able to access the backend cansiter. The system seems to be able to call the replica and load rooms from the canisters. To get it to work you need to run npm run dev which starts the backend canister, the downside is that the hot relating links will call the deployed canisters from npm run dev which means that those pages are not hot reloading. But at least the calls work

Working with the UI spun up by npm run vite has the advantage that it supports hot reloading for changes made to the UI so one doesn't need to redeploy on every UI change.
that's not the case for the UI canister spun up with
dfx deploy --argument "(
principal\"$(dfx identity get-principal)\",
record {
logo = record {
logo_type = \"image/png\";
data = \"\";
};
name = \"PersonalWebSpace\";
symbol = \"PWS\";
maxLimit = 65535;
}
)"
after running that command you get sth like
Deployed canisters.
URLs:
Frontend canister via browser
PersonalWebSpace_frontend: http://127.0.0.1:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai
Backend canister via Candid interface:
PersonalWebSpace_backend: http://127.0.0.1:4943/?canisterId=r7inp-6aaaa-aaaaa-aaabq-cai&id=rrkah-fqaaa-aaaaa-aaaaq-cai
http://127.0.0.1:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai doesn't work properly for me either (calls to the backend are also rejected) but http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai actually works (which usually should be the same as far as I know but it might be that my Linux subsystem setup messes this up)
thus, http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai can also call the backend successfully
creating a space still fails though as the local IC replica doesn't have the protocol canister running (which our backend uses). We could comment out the call to the protocol canister from the backend canister though (see comment with Local vs Mainnet Development in main.mo).
After commenting out the protocol call, the call to create a space is successful. Note that the preview shown in the section My Spaces points to the mainnet UI canister (i.e. doesn't show the local canisters). To see the local canister go to http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai#/space/0 (might need to refresh to work).
for accessing routes with this, one can use e.g.
http://localhost:4943/?canisterId=ryjl3-tyaaa-aaaaa-aaaba-cai#/testroom
the disadvantage here is that there isn't any hot reloading, so after every change one has to redeploy the canisters with
dfx deploy --argument "(
principal\"$(dfx identity get-principal)\",
record {
logo = record {
logo_type = \"image/png\";
data = \"\";
};
name = \"PersonalWebSpace\";
symbol = \"PWS\";
maxLimit = 65535;
}
)"

Running Bebb Protocol locally:
This project's dfx.json specifies Bebb Protocol as a remote canister (i.e. can be used by project's canisters locally but isn't built as it relies on the remote canister being deployed to the local replica from another project). It's canister bebbprotocol. The files for the integration (wasm, did, js, ts) need to be copied over to the integrations/BebbProtocol folder manually if changed.
Clone Bebb Protocol's repo: https://github.com/Bebb-Protocol-and-Apps/BebbProtocol
And use the latest version (e.g. 0.0.4 as of 2023-07)
Go to OIM's codebase (where the file you're reading is in)
Start a local replica in this project (OIM)
Deploy this project's canisters, PersonalWebSpace_backend and PersonalWebSpace_frontend, see deploy command in README (after these steps the following canister ids should be assigned: PersonalWebSpace_backend canister id: rrkah-fqaaa-aaaaa-aaaaq-cai; PersonalWebSpace_frontend canister id: ryjl3-tyaaa-aaaaa-aaaba-cai)
Go to the folder with Bebb Protocol's latest version and run dfx deploy there (this creates the local Bebb Protocol canister on the local replica started earlier which is thus the same replica this project's canisters are running on)
Make sure the local canister id for the deployed Bebb Protocol canister is br5f7-7uaaa-aaaaa-qaaca-cai (required by this project to make the calls on the local replica)
This project's canisters should now successfully call the locally deployed Bebb Protocol canister (i.e. all functionality works, same as on mainnet)
Test via npm run vite

34 changes: 17 additions & 17 deletions NotesOnStages.md → notes/NotesOnStages.md
View file
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
For development and testing, additional stages have been created, i.e. canisters live on the mainnet.

Process to create another stage:
Initial reference: https://medium.com/@Catalyze.One/working-with-environments-on-the-internet-computer-59ed3d2a5763
Go to https://nns.ic0.app/ and log in
From the burger menu, choose My Canisters
Click on Create Canister and follow the creation flow (note that you need ICP to pay for the creation and charge the canister with cycles), you may start with 3T cycles (and can top up later)
Click on the new canister and then on Add Controller
Go to your local CLI and run: dfx identity get-principal
Copy the principal returned and paste it into the Add Controller field on the nns app, continue and confirm
Copy the id of the new canister
Paste the canister's id in the file canister_ids.json (under the new entry for the stage, the entry's ket needs to match the network name given in dfx.json)
Create a new networks entry in dfx.json (with the network's name being the same key as given in canister_ids.json)
If there are multiple canisters for a stage, create as many canisters as needed (e.g. PersonalWebSpace_backend and PersonalWebSpace_frontend)
Add the CLI command/s in Readme for the new stage (with the correct network name)
Make sure that all code relevant for stages/networks has been changed (e.g. search for network and check all relevant results in the project files)
Run the new CLI command/s in Readme and make sure everything works as expected (just just deploy the new canister/s)
For development and testing, additional stages have been created, i.e. canisters live on the mainnet.

Process to create another stage:
Initial reference: https://medium.com/@Catalyze.One/working-with-environments-on-the-internet-computer-59ed3d2a5763
Go to https://nns.ic0.app/ and log in
From the burger menu, choose My Canisters
Click on Create Canister and follow the creation flow (note that you need ICP to pay for the creation and charge the canister with cycles), you may start with 3T cycles (and can top up later)
Click on the new canister and then on Add Controller
Go to your local CLI and run: dfx identity get-principal
Copy the principal returned and paste it into the Add Controller field on the nns app, continue and confirm
Copy the id of the new canister
Paste the canister's id in the file canister_ids.json (under the new entry for the stage, the entry's ket needs to match the network name given in dfx.json)
Create a new networks entry in dfx.json (with the network's name being the same key as given in canister_ids.json)
If there are multiple canisters for a stage, create as many canisters as needed (e.g. PersonalWebSpace_backend and PersonalWebSpace_frontend)
Add the CLI command/s in Readme for the new stage (with the correct network name)
Make sure that all code relevant for stages/networks has been changed (e.g. search for network and check all relevant results in the project files)
Run the new CLI command/s in Readme and make sure everything works as expected (just just deploy the new canister/s)
If you have any other projects depending on the canisters or that the canisters depend on, make sure to handle this accordingly (e.g. Bebb Protocol canisters: create a corresponding stage canister there and deploy it, make sure the canisters here reference that canister then for the correct stage, e.g. in dfx.json and look for Different Stages in motoko files)
Loading

0 comments on commit 95ef7c9

Please sign in to comment.