-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dockerfile and cargo-generate template for building programs #57
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
I like this idea a lot. Can you add the instructions for use to the readme? |
will do. but this still needs some work first. Currently, it is outputting the binary as part of the docker image build process. This means every time we compile a program we have to go through the whole process of installing rust and compiling wasm-tools etc. I am gonna change it to be able to build programs when running the container. |
Im a bit stuck on this. I've tried making a separate docker image with everything already installed, and using it as the base of this script. That is, i have a Dockerfile which looks like this: FROM rust:1.75 AS base
RUN rustup target add wasm32-unknown-unknown
RUN rustup target add wasm32-wasi
RUN cargo install cargo-component --version 0.2.0
RUN cargo install wasm-tools and i have published that to dockerhub and using it as the base image to build a program like this: FROM pegpegpeg/build-entropy-programs:latest AS base
ARG PACKAGE=template-barebones
WORKDIR /usr/src/programs
COPY . .
RUN cargo component build --release -p $PACKAGE --target wasm32-unknown-unknown
FROM scratch AS binary
COPY --from=base /usr/src/programs/target/wasm32-unknown-unknown/release/*.wasm / But for some reason it still seems to install the rust toolchain every time i build a program, and building the example programs takes almost 2 minutes. Its as if cargo component is internally installing everything a second time. |
@ameba23 if it's trying to download extra stuff, did you try throwing in a |
In the end it seems this problem goes away if i build a 'standalone' program rather than one of the examples in this repo. I think this might be because of there being a Either way, i now have one dockerfile for building the examples here, and one for building standalone programs, which can be started by doing |
Cargo.toml
Outdated
@@ -1,5 +1,6 @@ | |||
[workspace] | |||
members = ["programs", "core", "acl", "evm", "runtime", "examples/*"] | |||
exclude = ["examples/basic-template"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excluding the cargo-generate template because it has some syntax related to cargo-generate which means it wont build as a normal crate.
## Running Tests | ||
|
||
Before running the runtime tests, you need to build the `template-barebones` and `infinite-loop` components. To do this, execute: | ||
Before running the runtime tests, you need to build the `template-barebones`, `infinite-loop` and `example-custom-hash` components. To do this, execute: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to this PR but this was missing
cargo-generate.toml
Outdated
@@ -0,0 +1,2 @@ | |||
[template] | |||
sub_templates = ["examples/basic-template"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to demonstrate that we can have sub-templates for cargo-generate.
When they user runs cargo generate entropyxyz/programs
they will be prompted for which sub-template they want. So we could have sub-templates for different sorts of programs.
As it is, there is only one so not much point in it. But i just wanted to show how it could be done.
templates/basic-template/Cargo.toml
Outdated
docker-image = "pegpegpeg/build-entropy-programs:latest" | ||
|
||
# Configuration interface | ||
# configuration-interface = "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an idea - we could include configuration-interface JSON as part of the package metadata
@@ -20,7 +20,13 @@ cargo install cargo-component --version 0.2.0 && | |||
cargo install wasm-tools | |||
``` | |||
|
|||
## A Barebones Program: [`template-barebones`](./examples/barebones/src/lib.rs) | |||
Alternatively you can build them using the included Dockerfile: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah perfect, I missed this part in my original review.
This adds two things:
cargo-generate
, which contains a Dockerfile for building the program.If this is merged, it will be possible to get started building a new program with
cargo generate entropyxyz/programs
.To try it out right now, you can do
cargo generate --path <local path of this repo>
This assumes cargo-generate is installed:
cargo install cargo-generate
.Developers can then build their program 'deterministically' with
docker build --output=binary-dir .
, which will build the program and put the.wasm
file in./binary-dir
.The name of the docker image used to build the program is included as additional metadata in the program's
Cargo.toml
file. This means anyone with access to the program's source code can independently verify the program binary (or hash) by building it with the same image.To build the examples in this repo using docker you can also do:
docker build --build-arg PACKAGE=<example name> --output=example-binary .
from the top level of this repo.