feat: dockerize evm-prover service and add to compose network#171
feat: dockerize evm-prover service and add to compose network#171
Conversation
Add complete Docker infrastructure for evm-prover service including multi-stage build, SP1 toolchain, health checks, and docker-compose integration. Resolves #81
damiannolan
left a comment
damiannolan
left a comment
There was a problem hiding this comment.
Thank you @blasrodri! 🙏🏻
I left some comments/feedback, lemme know what you think!
There was a problem hiding this comment.
similarly if we want some custom docker-entrypoint.sh for our envirnoment we can put it inside testnet/evm-prover
Add evm-prover image build step to GitHub Actions docker workflow. The workflow now builds and pushes both hyperlane-init and evm-prover images to GHCR on pushes to main branch.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
damiannolan
left a comment
damiannolan
left a comment
There was a problem hiding this comment.
Have you run the docker compose network since adding the prover service?
I'm curious how the block prover loop will work when we haven't specified the SP1_PROVER env variable, since we instantiate the prover client with from_env().
It's possible we may need to add the SP1_PROVER=mock as an env variable to the container
|
The image fails to build for me on any ideas? |
|
I'm still getting: Not sure if the PR is intended to be ready for review or not, should we convert it to draft? |
Yes, I will put it as draft until I'm fully able to run it locally first. |
|
Finally, I removed all the caching optimizations because they were giving some errors due to certain structs not being found when they were there. I rather focus on having a working image first, and then improve it later on if we deem the build times too long. |
Improved the Dockerfile caching by adding cargo fetch between copying the manifests and copying the source code
damiannolan
left a comment
damiannolan
left a comment
There was a problem hiding this comment.
Happy to merge if we add a profile to have it disabled in default mode 🙏🏻
- Resolved conflicts in .github/workflows/docker.yml by using v6 of docker/build-push-action and adding arm64 platform support - Re-applied cargo-sort CI check from issue #164
Makes the ev-prover service optional by adding a 'prover' profile. This allows the service to be excluded from default docker compose up and only started explicitly when needed. Usage: - docker compose --profile prover up - docker compose up ev-prover - docker compose run ev-prover This keeps the service optional for the e2e demo flow while still allowing it to be deployed when needed.
| tags: ghcr.io/${{ github.repository_owner }}/hyperlane-init:latest | ||
|
|
||
| - name: Build and push ev-prover Docker image | ||
| uses: docker/build-push-action@v6 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
damiannolan
left a comment
damiannolan
left a comment
There was a problem hiding this comment.
I think we should address the docker workflow and remove the unneeded bind mount before we merge, otherwise lgtm
| platforms: linux/amd64,linux/arm64 | ||
| tags: ghcr.io/${{ github.repository_owner }}/hyperlane-init:latest | ||
|
|
||
| - name: Build and push ev-prover Docker image |
There was a problem hiding this comment.
I wonder if it would be better to create a separate workflow job for this so that we can have different build triggers.
Right now this workflow triggers a rebuild on merge to main when only the following the paths are changed, which doesn't make sense.
paths:
- '**/Dockerfile'
- '.github/workflows/docker.yml'
- 'hyperlane/**'
We should likely only trigger builds of ev-prover when those files are changed and separate these
There was a problem hiding this comment.
yes - now it's only on changes on this repo
| # Function to initialize the service | ||
| init_service() { | ||
| echo "Initializing ev-prover service..." | ||
| /app/ev-prover init |
There was a problem hiding this comment.
Because you run init in the entrypoint here I think you don't need to actually mount the genesis file at all, as there is a default genesis in ev-prover/resources which I think is included in the binary.
Should be possible to omit that bind mount
There was a problem hiding this comment.
you're right - i have addressed it
- Split docker.yml into separate jobs for hyperlane-init and ev-prover builds - Add conditional execution to only trigger builds when relevant files change - Remove unnecessary genesis.json bind mount from ev-prover service (genesis is embedded in binary and written by init command)
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 | ||
| with: | ||
| install: true |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
| install: true | ||
|
|
||
| - name: Log in to GitHub Container Registry | ||
| uses: docker/login-action@v3 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
| registry: ghcr.io | ||
| username: ${{ github.actor }} | ||
| password: ${{ secrets.GITHUB_TOKEN }} | ||
|
|
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
2 participants
Add complete Docker infrastructure for evm-prover service including multi-stage build, SP1 toolchain, health checks, and docker-compose integration.
Resolves #81
Overview