Here’re some high-level notes (of course that is not so linear, especially if you consider that it’d run in the cloud). Managed to reduce a 20m build to 5~8m.
My use-case is a test runner, in which git clone’s a remote repository and performs tests against it. This is a Rust project for the IC.
- Assumes that required binaries, libraries exist in the container or VM (these are pre-compiled to the target architecture, macosx, linux distro, added to PATH and /usr/local/bin )
- The remote repository is cloned and saved in a temporary directory
- Gets the remote repository HEAD commit hash, used to control if to use cached version
- Copy temporary directory content to a work directory (depending on cache assertion, as mentioned in the previous point, otherwise skips)
- Starts the dfx network by using the flags --background, --clean, --emulator.The network process is placed in the background otherwise would block the process. Clean, to prevent errors such as *1 Bad request for non existing canister.
- When running
dfx deploy after the
dfx start, a long process will occur, but if the repository is the cached version the process will be much faster by several times, but this is only possible if the
dfx start network is started with
--clean, as it won’t make it compile everything again which is what takes a lot of time, but will
install code for canister, instead of upgrading, which is ok as its fast enough.
NOTE: At time of writing this was run on a MacOS VM, as the project was written in MacOS, and because there were issues building the project on Ubuntu Linux; ideally, if using a Docker image with most binaries pre-compiled this might be faster, surely.
(*1) - when a cached repository, contained
.dfx and other artifacts previously built against a different network
dfx start, the following happens:
Installing code for canister dank, with canister_id xxxxxxxxxxxx
The replica returned an HTTP Error: Http Error: status 400 Bad Request, content type "text/plain", content: canister does not exist: xxxxxxxxxxx