Deploy an app twice on the IC (Staging env)

Ok…I’ve done something horribly wrong and nothing is making sense anymore. Anyone have any reason why this would work:

dfx canister --network local install canister_dev --mode=reinstall --argument '(record {owner =principal  "6i6da-t3dfv-vteyg-v5agl-tpgrm-63p4y-t5nmm-gi7nl-o72zu-jd3sc-7qe"})'

But this right after it would not:

dfx canister --network ic install canister_dev --mode=reinstall --argument '(record {owner =principal  "6i6da-t3dfv-vteyg-v5agl-tpgrm-63p4y-t5nmm-gi7nl-o72zu-jd3sc-7qe"})'

It returns:

Do you want to proceed? yes/No
yes
Reinstalling code for canister canister_dev, with canister_id frfol-iqaaa-aaaaj-acogq-cai
Error: No such file or directory (os error 2)

To fix this I had to create different entries in my dfx.json called canister_stage and canister_dev. I had to make them custom and point to the wasm produced when I build canister. A bit of a hack bu the file not found error went away.

1 Like

Hi guys,

Also getting same error during deployment. I can perform all commands through “–network dev” except “install”. Is there any fix or explanation what is wrong?

“Creating UI canister on the dev network.
Error: The replica returned an HTTP Error: Http Error: status 404 Not Found”

2 Likes

We’ve got this working by setting the key __Candid_UI on our canister_ids.json like so (canister_ids are just examples!):

{
  "__Candid_UI": {
    "ic": "a2gq7-oaaaa-aaaab-qaa4q-cai",
    "YOUR_NETWORK_NAME": "a2gq7-oaaaa-aaaab-qaa4q-cai"
  },
  ...
}

Also important was that we set the wallet for the identity using this:

dfx identity --network dev set-wallet $(dfx identity --network ic get-wallet)
4 Likes

Yes. Works for me. Thanks!

2 Likes

I run a bash script to deploy my backend canisters one-by-one to the specified environment, but i am running into the issue that it tries to deploy a UI canister for every canister im trying to deploy :confused:

dfx deploy --network=dev group_management_controller --no-wallet

dev > Deploying group_management_controller canister..
Deploying: group_management_controller
All canisters have already been created.
Building canisters...
Executing 'cargo build -q --target wasm32-unknown-unknown --package  group_management_controller --release'
Executing 'ic-cdk-optimizer target/wasm32-unknown-unknown/release/group_management_controller.wasm -o target/wasm32-unknown-unknown/release/group_management_controller-opt.wasm'
Original:          2.77 MiB
Stripping Unused Data Segments...
    Size:          1.05 MiB (62.1% smaller)
Execute a binaryen optimization pass on your WASM....
    Size:          969.61 KiB (9.9% smaller)

Final Size: 969.61 KiB (65.8% smaller)
Installing canisters...
Creating UI canister on the dev network.
Error: The replica returned an HTTP Error: Http Error: status 404 Not Found, content type "text/html", content: <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.21.3</center>
</body>
</html>


dfx deploy --network=dev management_controller --no-wallet

 dev > Deploying management_controller canister..
Deploying: management_controller
All canisters have already been created.
Building canisters...
Executing 'cargo build -q --target wasm32-unknown-unknown --package  management_controller --release'
Executing 'ic-cdk-optimizer target/wasm32-unknown-unknown/release/management_controller.wasm -o target/wasm32-unknown-unknown/release/management_controller-opt.wasm'
Original:          2.53 MiB
Stripping Unused Data Segments...
    Size:          855.98 KiB (66.9% smaller)
Execute a binaryen optimization pass on your WASM....
    Size:          773.42 KiB (9.6% smaller)

Final Size: 773.42 KiB (70.1% smaller)
Installing canisters...
Creating UI canister on the dev network.
Error: The replica returned an HTTP Error: Http Error: status 404 Not Found, content type "text/html", content: <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.21.3</center>
</body>
</html>

etc..

@rem.codes would you mind sharing how you define the ‘dev’ network? The code is quite clear that the UI canister should only be deployed if the network is NOT the real IC. I suspect the problem is either with a) how the network is specified or b) how we determine if it’s the real IC or not.

Thanks for the quick response, my dfx.json has this

"networks": {
    "dev": {
      "providers": [
        "https://ic0.app/"
      ],
      "type": "persistent"
    }
  }

Remove the trailing slash in the provider and it will recognise it as a real IC network. I’ll make a PR that fixes this.

3 Likes

Awesome, this fixed it! Thanks :superhero:

1 Like

Dumb question, but everyone who is deploying canisters to staging (which simply points to the IC mainnet) is still paying cycles to do so, right?

Yes, there’s no way around paying cycles for that.

Ok, now everybody is able to get a staging environment up and running, but what strategies do you apply in order to differentiate staging from production and also let Kinic our new search engine know?

I’m still facing some of the issues that people have raised in this thread.

Context

I’m using the Cycles ledger to manage my cycles.
I have deployed two canisters, named backend and frontend, a while ago on mainnet.
Now, I want to deploy the same canisters as “staging” to test out some new features before shipping them to the already existing “production” canisters.

Problem

Here are the steps I made to create a staging deployment environment next to the already existing production environment:

  1. Temporarily removed the canister_ids.json file
  2. Deployed my two canisters as if they were new mainnet canisters with the following command:
    dfx deploy --ic --no-wallet
    
  3. Added the “old” production canisters again to the newly created canister_ids.json file, and renamed the new canister network keys from ic to staging. Here’s the canister_ids.json updated file:
    {
        "backend": {
            "staging": "<canister-id-just-created>",
            "ic": "<canister-id-already-existing>"
        },
        "frontend": {
            "staging": "<canister-id-just-created>",
            "ic": "<canister-id-already-existing>"
        }
    }
    
  4. Added the staging network to the dfx.json file:
    {
        "canisters": {
            "backend": {...},
            "frontend": {...}
        },
        "networks": {
            ...
            "staging": {
                "providers": ["https://icp-api.io"],
                "type": "persistent"
            }
        }
    }
    
  5. Deployed both canisters again using the following command:
    dfx deploy --network staging --no-wallet
    
  6. Got the error:
    Installing canisters...
    Creating UI canister on the staging network.
    Error: Failed while trying to deploy canisters.
    Caused by: Failed while trying to install all canisters.
    Caused by: Failed to install wasm module to canister 'backend'.
    Caused by: Failed to install candid UI canister.
    Caused by: Create canister call failed.
    Caused by: The replica returned a rejection error: reject code CanisterReject, reject message Caller <my-principal> is not allowed to call ic00 method provisional_create_canister_with_cycles, error code Some("IC0406")
    

Workaround

The workaround found by @Litzi seems to work for me as well:

With one small difference: the Candid UI mainnet canister id is now a4gq6-oaaaa-aaaab-qaa4q-cai.

1 Like

Change this to "providers": ["https://icp0.io"], and you should be good to go. dfx’s logic to detect mainnet is too simplistic and it currently only accepts this one domain. I’ll see if we can improve that

1 Like