ci(workflows) add GitHub Actions workflow for preview builds - #2446
Conversation
This commit introduces a new GitHub Actions workflow file, `preview.yml`, to automate building and deploying Docker images. The workflow includes steps for setting up the Rust toolchain, building binaries, archiving artifacts, and deploying them via Docker and Slot. This enhancement streamlines the CI/CD process, ensuring consistency and efficiency in releases.
WalkthroughOhayo, sensei! This pull request introduces a GitHub Actions workflow named Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant GitHub Actions
participant Rust Build
participant Docker Build
User->>GitHub Actions: Trigger workflow (manual)
GitHub Actions->>Rust Build: Checkout code
Rust Build-->>GitHub Actions: Build binaries (katana, torii, sozo)
Rust Build-->>GitHub Actions: Archive binaries
GitHub Actions->>Docker Build: Checkout code
Docker Build->>GitHub Actions: Download binaries
Docker Build->>GitHub Container Registry: Build and push Docker image
Recent review detailsConfiguration used: .coderabbit.yaml Files selected for processing (1)
Additional context usedactionlint
Additional comments not posted (3)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Outside diff range and nitpick comments (1)
.github/workflows/preview.yml (1)
74-76: Remove temporary debug step 'TEMP LS'Ohayo, sensei! The 'TEMP LS' step appears to be a temporary debugging step. If it's no longer needed, consider removing it to clean up the workflow.
Apply this diff to remove the step:
- - name: TEMP LS - run: ls -R artifacts
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/preview.yml (1 hunks)
Additional context used
actionlint
.github/workflows/preview.yml
22-22: the runner of "Swatinem/rust-cache@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
38-38: property "prepare" is not defined in object type {}
(expression)
39-39: shellcheck reported issue in this script: SC2086:info:2:61: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: the runner of "actions/checkout@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
78-78: the runner of "docker/setup-buildx-action@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
81-81: the runner of "docker/login-action@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
89-89: shellcheck reported issue in this script: SC2086:info:2:51: Double quote to prevent globbing and word splitting
(shellcheck)
| run: ls -R artifacts | ||
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v1 |
There was a problem hiding this comment.
Update docker/setup-buildx-action to the latest version
Ohayo, sensei! The docker/setup-buildx-action@v1 action is outdated. Updating to the latest version ensures improved functionality and support.
Apply this diff to update the action version:
- - name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v1
+ - name: Set up Docker Buildx
+ uses: docker/setup-buildx-action@v2Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: docker/setup-buildx-action@v1 | |
| uses: docker/setup-buildx-action@v2 |
Tools
actionlint
78-78: the runner of "docker/setup-buildx-action@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v2 |
There was a problem hiding this comment.
Update actions/checkout action to the latest version
Ohayo, sensei! The actions/checkout@v2 action is outdated. Updating to the latest version will provide consistency and utilize the latest features.
Apply this diff to update the action version:
- uses: actions/checkout@v2
+ uses: actions/checkout@v4Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/checkout@v2 | |
| uses: actions/checkout@v4 |
Tools
actionlint
66-66: the runner of "actions/checkout@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
| steps: | ||
| - uses: actions/checkout@v4 | ||
|
|
||
| - uses: Swatinem/rust-cache@v1 |
There was a problem hiding this comment.
Update Swatinem/rust-cache action to a newer version
Ohayo, sensei! The Swatinem/rust-cache@v1 action is outdated. Updating to the latest version will ensure better compatibility and performance.
Apply this diff to update the action version:
- - uses: Swatinem/rust-cache@v1
+ - uses: Swatinem/rust-cache@v2Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: Swatinem/rust-cache@v1 | |
| - uses: Swatinem/rust-cache@v2 |
Tools
actionlint
22-22: the runner of "Swatinem/rust-cache@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
| uses: docker/setup-buildx-action@v1 | ||
|
|
||
| - name: Login to GitHub Container Registry | ||
| uses: docker/login-action@v1 |
There was a problem hiding this comment.
Update docker/login-action to the latest version
Ohayo, sensei! The docker/login-action@v1 action is outdated. Updating to the latest version will enhance security and compatibility.
Apply this diff to update the action version:
- - name: Login to GitHub Container Registry
- uses: docker/login-action@v1
+ - name: Login to GitHub Container Registry
+ uses: docker/login-action@v2Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: docker/login-action@v1 | |
| uses: docker/login-action@v2 |
Tools
actionlint
81-81: the runner of "docker/login-action@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
| id: vars | ||
| run: | | ||
| git config --global --add safe.directory '*' | ||
| echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
ShellCheck SC2086: Quote variables to prevent globbing and word splitting
Ohayo, sensei! In your shell script, the variable $GITHUB_OUTPUT should be wrapped in double quotes to prevent word splitting and globbing issues.
Apply this diff to fix the issue:
- echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
+ echo "sha_short=$(git rev-parse --short HEAD)" >> "$GITHUB_OUTPUT"Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT | |
| echo "sha_short=$(git rev-parse --short HEAD)" >> "$GITHUB_OUTPUT" |
| - name: Archive binaries | ||
| id: artifacts | ||
| env: | ||
| VERSION_NAME: v${{ needs.prepare.outputs.tag_name }} |
There was a problem hiding this comment.
Undefined 'prepare' in 'needs.prepare.outputs.tag_name'
Ohayo, sensei! The variable needs.prepare.outputs.tag_name refers to a job named prepare, which isn't defined in the workflow. This will cause the workflow to fail due to an undefined reference.
To fix this, either define a prepare job that outputs tag_name, or modify the variable to correctly reference an existing job's output. If tag_name is not needed, you can set a default value.
For example, set VERSION_NAME to a default value:
- VERSION_NAME: v${{ needs.prepare.outputs.tag_name }}
+ VERSION_NAME: "v1.0.0" # Replace with the appropriate versionCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| VERSION_NAME: v${{ needs.prepare.outputs.tag_name }} | |
| VERSION_NAME: "v1.0.0" # Replace with the appropriate version |
Tools
actionlint
38-38: property "prepare" is not defined in object type {}
(expression)
| VERSION_NAME: v${{ needs.prepare.outputs.tag_name }} | ||
| run: | | ||
| tar -czvf "dojo_${VERSION_NAME}_linux_amd64.tar.gz" -C ./target/release katana torii sozo | ||
| echo "file_name=dojo_${VERSION_NAME}_linux_amd64.tar.gz" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
ShellCheck SC2086: Quote variables to prevent globbing and word splitting
Ohayo, sensei! In your shell script, the variable $GITHUB_OUTPUT should be wrapped in double quotes to prevent word splitting and globbing issues.
Apply this diff to fix the issue:
- echo "file_name=dojo_${VERSION_NAME}_linux_amd64.tar.gz" >> $GITHUB_OUTPUT
+ echo "file_name=dojo_${VERSION_NAME}_linux_amd64.tar.gz" >> "$GITHUB_OUTPUT"Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| echo "file_name=dojo_${VERSION_NAME}_linux_amd64.tar.gz" >> $GITHUB_OUTPUT | |
| echo "file_name=dojo_${VERSION_NAME}_linux_amd64.tar.gz" >> "$GITHUB_OUTPUT" |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2446 +/- ##
==========================================
+ Coverage 68.21% 68.30% +0.09%
==========================================
Files 365 365
Lines 48022 48034 +12
==========================================
+ Hits 32757 32809 +52
+ Misses 15265 15225 -40 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range and nitpick comments (1)
.github/workflows/preview.yml (1)
65-67: Consider removing the 'TEMP LS' debug stepOhayo, sensei! The
TEMP LSstep seems to be a temporary debugging step. Consider removing it to keep the workflow clean and efficient.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/preview.yml (1 hunks)
Additional comments not posted (2)
.github/workflows/preview.yml (2)
17-17: Verify the runner label 'ubuntu-latest-4-cores'Ohayo, sensei! The runner label
ubuntu-latest-4-coresis not a standard GitHub-hosted runner. Please verify that this label refers to a valid self-hosted runner in your environment or consider usingruns-on: ubuntu-latestfor GitHub-hosted runners.
88-88: Tagging strategy is properly implementedOhayo, sensei! The tagging strategy using the short SHA from
steps.vars.outputs.sha_shortis correctly implemented and will help in identifying the image versions.
| - uses: arduino/setup-protoc@v2 | ||
| with: | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} | ||
| version: "25.x" | ||
|
|
There was a problem hiding this comment.
Remove unnecessary 'repo-token' input from 'arduino/setup-protoc@v2'
Ohayo, sensei! The repo-token input is not required for the arduino/setup-protoc@v2 action. Removing it can prevent potential misconfigurations.
Apply this diff to remove the unnecessary input:
- uses: arduino/setup-protoc@v2
with:
- repo-token: ${{ secrets.GITHUB_TOKEN }}
version: "25.x"Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: arduino/setup-protoc@v2 | |
| with: | |
| repo-token: ${{ secrets.GITHUB_TOKEN }} | |
| version: "25.x" | |
| - uses: arduino/setup-protoc@v2 | |
| with: | |
| version: "25.x" | |
There was a problem hiding this comment.
Actionable comments posted: 4
Outside diff range and nitpick comments (5)
Dockerfile (2)
18-18: Consider adding SHA256 checksum verification for enhanced security.To ensure the integrity of the downloaded Tini binary, it's a good idea to verify its SHA256 checksum.
You can modify the
ADDinstruction like this:ENV TINI_VERSION v0.19.0 ENV TINI_SHA256 93dcc18adc78c65a028a84799ecf8ad40c936fdfc5f2a57b1acda5a8117fa82c ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini RUN echo "${TINI_SHA256} */tini" | sha256sum -c - \ && chmod +x /tiniThis downloads Tini, verifies its SHA256 checksum matches the expected value, and then makes it executable in a single
RUNlayer to keep the image lean.
Line range hint
1-16: Heads up sensei: Thebuilderstage is missing Tini.Looks like the
builderstage, where thecurtailertool is built and installed, doesn't include Tini. Ifcurtaileror its build process spawns child processes, you might run into zombie process issues in that stage.Consider if the
builderstage also needs Tini. If so, you can install it there similarly to the final stage, before running the build commands..github/Dockerfile (3)
1-1: Ohayo sensei! Consider using a more specific base image.Using a specific version tag like
rust:1.80.0-slimis great for reproducibility. However, consider using a more specific tag likerust:1.80.0-slim-busterto pin the underlying OS version as well. This will further improve reproducibility and avoid potential issues if the default OS version changes in the future.
13-14: Consider using a singleRUNinstruction for Rust setup.To reduce the number of layers in the final image, consider combining the
rustupcommands into a singleRUNinstruction.Here's how you can combine them:
RUN rustup install 1.79.0 && \ rustup component add cargo clippy rust-docs rust-std rustc rustfmt
22-22: Consider using a more specific recipe path.Using
recipe.jsonas the recipe path is fine. However, consider using a more specific path like/app/recipe.jsonto avoid potential conflicts if there are otherrecipe.jsonfiles in the project.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (4)
- .dockerignore (1 hunks)
- .github/Dockerfile (1 hunks)
- .github/workflows/preview.yml (1 hunks)
- Dockerfile (1 hunks)
Files skipped from review due to trivial changes (1)
- .dockerignore
Additional context used
actionlint
.github/workflows/preview.yml
44-44: shellcheck reported issue in this script: SC2046:warning:2:20: Quote this to prevent word splitting
(shellcheck)
Additional comments not posted (6)
Dockerfile (1)
17-20: Ohayo sensei! The Tini integration looks great.The changes to add Tini as the init system for the container follow best practices. Key points:
- Specifying the Tini version as an environment variable allows for easy updates in the future.
- Downloading Tini from the official GitHub releases ensures authenticity.
- Setting the executable permission on the Tini binary is necessary.
- Using Tini as the entrypoint enables it to be the init process (PID 1).
Tini will help manage zombie processes and forward signals properly to the main process. Nice work!
.github/Dockerfile (4)
7-7: ****
10-11: Verify theLIBCLANG_PATHis correctly set.Finding and exporting the
LIBCLANG_PATHis a good practice. However, it's worth double-checking that the path is correctly set and accessible within the container.You can verify it by adding an
echo $LIBCLANG_PATHcommand after theexportline and building the image to check the output.
16-16: LGTM!Installing
cargo-chefis a great way to optimize the build process and leverage caching.
29-30: Excellent use ofcargo cheffor caching dependencies!Using
cargo chef cookto build and cache dependencies is a great optimization technique. It significantly speeds up subsequent builds by leveraging the Docker layer caching mechanism..github/workflows/preview.yml (1)
1-57: LGTM!Ohayo, sensei! The new GitHub Actions workflow looks great. It effectively automates the process of building and pushing Docker images for preview builds. The workflow is well-structured, utilizing caching and output variables to optimize the build process. The use of Docker Buildx and the GitHub Container Registry streamlines the CI/CD pipeline.
No major issues or concerns were identified during the review. The workflow should function as intended, enhancing the efficiency of the development workflow.
Tools
actionlint
44-44: shellcheck reported issue in this script: SC2046:warning:2:20: Quote this to prevent word splitting
(shellcheck)
steebchen
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (1)
.github/Dockerfile (1)
38-45: Sensei, the final stage can be simplified by using a singleCOPYinstruction.Instead of using multiple
COPYinstructions to copy the built binaries, consider using a singleCOPYinstruction with wildcards to simplify the Dockerfile.Here's how you can refactor it:
FROM rust:1-alpine WORKDIR / COPY --from=builder /app/target/release/{katana,torii,sozo,saya} /app/artifacts/This will copy all the specified binaries in a single instruction, reducing the number of layers in the final image.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (4)
- .dockerignore (1 hunks)
- .github/Dockerfile (1 hunks)
- .github/workflows/preview.yml (1 hunks)
- .gitignore (1 hunks)
Files skipped from review due to trivial changes (1)
- .gitignore
Files skipped from review as they are similar to previous changes (2)
- .dockerignore
- .github/workflows/preview.yml
Additional comments not posted (2)
.github/Dockerfile (2)
1-16: Ohayo sensei! Thechefstage looks great!The
apt-getcommands are combined to reduce the number of layers and the final image size. Theaptcache is also cleaned up to further reduce the image size. TheLIBCLANG_PATHenvironment variable is set correctly, and the Rust toolchain and components are installed correctly. Thecargo-cheftool is also installed correctly.
18-22: Theplannerstage is set up correctly, sensei!The
plannerstage is correctly based on thechefstage, and the working directory is set correctly. The application code is copied correctly, and thecargo chef preparecommand is used correctly to generate the recipe file.
| FROM chef AS builder | ||
|
|
||
| WORKDIR /app | ||
| COPY --from=planner /app/recipe.json recipe.json | ||
| # Build dependencies - this is the caching Docker layer! | ||
| RUN cargo chef cook --release --recipe-path recipe.json | ||
| RUN cargo build --release --bins # pre-cache some stuff | ||
|
|
||
| # Build application | ||
| COPY . . | ||
| ENV PATH="/root/.cargo/bin:${PATH}" | ||
|
|
||
| RUN cargo build --release --bins |
There was a problem hiding this comment.
Sensei, there are a few things that can be improved in the builder stage.
The pre-caching step on line 30 is redundant since the same command is already executed on line 36. Consider removing the redundant command to simplify the Dockerfile and reduce build time.
Also, copying the application code again on line 33 is unnecessary since it was already copied in the planner stage. Setting the PATH environment variable on line 34 is also unnecessary since it is not used in the final image.
Here's how you can refactor it:
FROM chef AS builder
WORKDIR /app
COPY --from=planner /app/recipe.json recipe.json
# Build dependencies - this is the caching Docker layer!
RUN cargo chef cook --release --recipe-path recipe.json
RUN cargo build --release --binsThere was a problem hiding this comment.
this still caches building the deps, so it certainly speeds up the build when dependencies don't change
There was a problem hiding this comment.
@steebchen Ohayo, sensei! Thank you for the clarification. I understand now that the pre-caching step helps speed up the build when dependencies don't change. I'll keep this in mind for future reviews.
（・ｪ・）
Learnings added
Learnt from: steebchen
PR: dojoengine/dojo#2446
File: .github/Dockerfile:24-36
Timestamp: 2024-09-19T19:02:02.095Z
Learning: In the Dockerfile, the pre-caching step in the `builder` stage is important for caching dependencies and speeding up the build when dependencies don't change.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
5b0b2a3 to
cb80ecc
Compare
a6eccb0 to
cf7cc62
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (2)
.github/workflows/preview.yml (2)
26-33: Consider consolidating the caching steps.Ohayo, sensei! I noticed that there are two separate caching steps for Docker layers, one for
/tmp/.buildx-cache/prebuildand another for/tmp/.buildx-cache/build. Having two steps for the same purpose can be confusing and unnecessary. Consider consolidating them into a single caching step for clarity and simplicity.
81-89: Temporary fix acknowledged.Ohayo, sensei! The temporary fix for moving the Docker build cache is noted. It's good that the referenced GitHub issues are mentioned for context. While this fix is necessary for now, it's important to keep tracking those issues for a permanent solution. Consider adding a TODO comment to revisit this once the underlying issues are resolved.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/preview.yml (1 hunks)
Additional context used
actionlint
.github/workflows/preview.yml
11-11: label "ubuntu-latest-32-cores" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-14.0", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-13.0", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "macos-12.0", "macos-11", "macos-11.0", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
Additional comments not posted (9)
.github/workflows/preview.yml (9)
11-11: Verify the runner label.Ohayo, sensei! The runner label
ubuntu-latest-32-coresis not a standard GitHub-hosted runner label. If it's a custom label for a self-hosted runner, please ensure it's defined in theactionlint.yamlconfig file to avoid validation errors.Tools
actionlint
11-11: label "ubuntu-latest-32-cores" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-14.0", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-13.0", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "macos-12.0", "macos-11", "macos-11.0", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
14-15: LGTM!The usage of
docker/setup-buildx-action@v3looks good. It will set up Docker Buildx with the latest version of the action.
17-24: LGTM!The caching configuration for Docker layers looks good. It will help speed up subsequent builds by caching the layers specific to the branch and commit. The fallback restore keys are also properly configured.
35-36: LGTM!Using
actions/checkout@v4to check out the repository is the right approach. It ensures the latest version of the action is used.
38-43: LGTM!The configuration for logging in to the GitHub Container Registry looks good. Using
docker/login-action@v3with the appropriate registry, username, and password ensures secure authentication for pushing Docker images.
45-50: LGTM!Setting the
safe.directoryGit configuration and thesha_shortoutput variable is properly implemented. Using${{ github.workspace }}and$GITHUB_OUTPUTensures the correct values are set.
52-61: LGTM!The configuration for building the Docker image using
docker/build-push-action@v5looks good. The build context, Dockerfile path,loadoption, image tagging, cache options, and target platform are all properly set up.
63-68: LGTM!Building the local binaries using a Docker container is a good approach. Mounting the
artifactsdirectory and copying the built artifacts to the mounted volume ensures they are accessible on the host. Setting thePLATFORMenvironment variable tolinux/amd64is consistent with the target platform.
70-79: LGTM!The configuration for building and pushing the Docker image using
docker/build-push-action@v3looks good. Thepushoption, image tagging, cache options, target platform, and build contexts are all properly set up. Including theartifactsbuild context ensures the previously built artifacts are included in the image.
2 participants
Description
This commit introduces a new GitHub Actions workflow file,
preview.yml, to automate building and deploying Docker images. The workflow includes steps for setting up the Rust toolchain, building binaries, archiving artifacts, and deploying them via Docker. This enhancement streamlines the CI/CD process, ensuring consistency and efficiency in releases.Related issue
Tests
Added to documentation?
Checklist
scripts/prettier.sh,scripts/rust_fmt.sh,scripts/cairo_fmt.sh)scripts/clippy.sh,scripts/docs.sh)Summary by CodeRabbit
New Features
.dockerignorefile to optimize Docker image creation by excluding unnecessary files.Improvements
.gitignoreto keep the repository clean by ignoring build artifacts.