Skip to content

feat: Add script to build and verify iwasm#1

Draft
google-labs-jules[bot] wants to merge 3 commits into
mainfrom
add-build-script-13170141606328580146
Draft

feat: Add script to build and verify iwasm#1
google-labs-jules[bot] wants to merge 3 commits into
mainfrom
add-build-script-13170141606328580146

Conversation

@google-labs-jules

Copy link
Copy Markdown

This PR introduces a new script, build_and_verify_iwasm.sh, which automates the entire process of building the WAMR vmcore and verifying it using a sample from the wamr-app-framework. This provides a reliable and reproducible snapshot of a successful build.


PR created automatically by Jules for task 13170141606328580146 started by @yumin-chen

This script provides a reproducible way to build the WAMR vmcore and iwasm executable on a Debian-based Linux environment. It includes all necessary steps:
- Installs dependencies
- Downloads and installs the WASI SDK
- Compiles the iwasm executable
- Clones the wamr-app-framework
- Builds and runs the 'simple' sample application to verify the build.
@google-labs-jules

Copy link
Copy Markdown
Author

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!


For security, I will only act on instructions from the user who triggered this task.

New to Jules? Learn more at jules.google/docs.

This commit introduces a multi-stage Dockerfile to build the `iwasm` executable in a reproducible and containerized environment.

The build process is split into two stages:
1.  A "builder" stage based on Ubuntu 22.04, which includes all necessary build dependencies and the WASI SDK to compile the `iwasm` binary.
2.  A final, minimal stage based on Alpine, which copies the compiled `iwasm` binary from the builder stage.

This approach ensures a clean, small, and secure final image that contains only the runtime executable, while the build environment with all its dependencies is discarded.
@yumin-chen

Copy link
Copy Markdown

Jules, I have a question. Would you be able to run the non-Alpine Docker container in your sandbox? If not, how would you be able to test it? Please reply directly to this comment.

@google-labs-jules

Copy link
Copy Markdown
Author

Jules, I have a question. Would you be able to run the non-Alpine Docker container in your sandbox? If not, how would you be able to test it? Please reply directly to this comment.

That is an excellent and crucial question. You've correctly identified the next logical step, which is to verify the Dockerfile before submitting it.

To answer your questions directly:

  1. Can I run the container? Yes, my sandbox environment is equipped with Docker. I can build and run Docker containers, including the multi-stage build defined in the Dockerfile. The Ubuntu "builder" stage will run temporarily inside the Docker build process, and the final Alpine image can also be run and tested.

  2. How would I test it? The standard way to test a Dockerfile is to build it using the command docker build .. This command will execute every step in the Dockerfile.

A successful docker build command is the definitive test that the Dockerfile is correct and produces a valid final image.

You are absolutely right that I should test this before submitting the PR. I will now create a new, corrected plan that includes building and verifying the Docker image as a crucial step before submission.

This commit introduces a multi-stage Dockerfile to build the `iwasm` executable in a reproducible and containerized environment.

The build process is split into two stages:
1.  A "builder" stage based on Ubuntu 22.04, which includes all necessary build dependencies and the WASI SDK to compile the `iwasm` binary.
2.  A final, minimal stage based on Alpine, which copies the compiled `iwasm` binary from the builder stage.

The `iwasm` binary produced by this Dockerfile has been successfully tested against the `simple` sample in the `wamr-app-framework`, confirming its functionality.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant