👷 Update CI/CD for cloudrun #113
Conversation
WalkthroughThe recent updates introduce comprehensive automation for deploying web applications to Google Cloud Run, catering to various stages of the development lifecycle including PR previews, staging, and release deployments. Enhancements include ignoring unnecessary files in Docker builds, setting up a Node.js environment for the web app, and streamlining the deployment process through GitHub Actions workflows. These changes facilitate efficient and automated management of Cloud Run services and their associated artifacts. Changes
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 3
Configuration used: CodeRabbit UI
Files selected for processing (6)
- .dockerignore (1 hunks)
- .github/workflows/deploy-cloudrun-pr-closed.yaml (1 hunks)
- .github/workflows/deploy-cloudrun-pr.yaml (1 hunks)
- .github/workflows/deploy-cloudrun-release.yaml (1 hunks)
- .github/workflows/deploy-cloudrun-stg.yaml (1 hunks)
- cloudrun/Dockerfile (1 hunks)
Files skipped from review due to trivial changes (1)
- .dockerignore
Additional comments: 13
cloudrun/Dockerfile (5)
- 4-4: Setting
BASE_URLas an environment variable at build time is a good practice for configurability. However, ensure that this value aligns with the application's expected base URL in different environments (development, staging, production). If the base URL varies across environments, consider passing it as a runtime environment variable instead.- 20-22: Copying minimal files from the builder stage to the production stage is a good practice for keeping the Docker image size small. However, ensure that all necessary runtime dependencies are included. If your application depends on
node_modules, you might need to adjust the build process to include only production dependencies in the final image.- 24-28: The environment variables
HOST,BASE_URL, andPORTare correctly set for the application's runtime. However, ensure that these values are appropriate for the production environment and that they do not conflict with any external configuration management or deployment settings.- 31-31: The command to start the application is clear and specifies the path to the server's entry point. Ensure that the
.output/server/index.mjsfile is correctly generated by the build process and that it is the correct entry point for your application.- 34-34: Exposing port 8080 is standard for web applications. Ensure that this port aligns with the application's configuration and the deployment environment's requirements. If the application is expected to run on a different port in certain environments, consider making the port configurable through environment variables.
.github/workflows/deploy-cloudrun-pr-closed.yaml (8)
- 1-1: The workflow name is descriptive and clearly indicates its purpose. This is good practice for maintainability and understanding the workflow's role within the CI/CD pipeline.
- 3-7: Triggering the workflow on pull request closure for the main branch is appropriate for the intended cleanup task. This ensures that resources are only cleaned up when changes are merged or abandoned, preventing premature deletion.
- 10-13: The permissions set for the workflow are minimal and appropriate for the tasks being performed, adhering to the principle of least privilege. This reduces the risk of unauthorized access or actions if the workflow's credentials were compromised.
- 15-21: Using the
google-github-actions/authaction for authentication is a secure and recommended way to handle Google Cloud credentials within GitHub Actions. Ensure that the service account used has only the necessary permissions for deleting Cloud Run services and Docker images.- 23-26: Setting up gcloud with the
google-github-actions/setup-gcloudaction is necessary for executing gcloud commands. Ensure that the specified version constraint ('>= 363.0.0') aligns with the features and commands used in the workflow.- 28-32: The command to delete the Cloud Run service is correctly formed and includes the
--quietflag to avoid interactive prompts. However, ensure that the naming convention for Cloud Run services (tokiwa23-stg-pr-${{ github.event.number }}) matches the convention used during deployment to avoid mismatches and failed deletions.- 34-38: Similarly, the command to delete the Docker image from Artifact Registry is well-formed. Ensure that the naming convention and path (
asia-northeast1-docker.pkg.dev/ynufes-hp-cloudrun/staging/tokiwa23-pr-${{ github.event.number }}:latest) match those used during the image push to ensure successful deletion.- 40-45: Posting a failure notification on the pull request if resource deletion fails is a good practice for visibility and troubleshooting. However, ensure that the GitHub token used has the necessary permissions to post comments on pull requests.
| FROM node:20-slim as builder | ||
| #nodeのイメージをベースにする |
There was a problem hiding this comment.
The comment in line 2 is written in Japanese, which might not be universally understood by all team members or contributors. Consider translating comments into English to maintain consistency and ensure that the codebase is accessible to a wider audience.
| COPY ./ ./ | ||
| #ynu-fes...の下を/appの下にコピー |
There was a problem hiding this comment.
Ensure that copying the entire project directory into the Docker image does not inadvertently include sensitive files or unnecessary files that could bloat the image size. It's good practice to use a .dockerignore file to exclude files not needed in the build context, such as local environment configurations, logs, or temporary files.
| RUN yarn install | ||
|
|
||
| RUN yarn build |
There was a problem hiding this comment.
The use of yarn install followed by yarn build is standard for Node.js applications. However, consider using yarn install --frozen-lockfile to ensure that the installed dependencies match the versions specified in yarn.lock, which can help prevent accidental updates and ensure consistent builds.
Cloud Run用にCI/CDを編集。
https://github.com/ynufes-tech/ynufes-cloudrun-cicd-demo
以上を参考に。
Summary by CodeRabbit
New Features
Dockerfileto streamline the building and running of the web application in a containerized environment.Chores
.dockerignoreto enhance Docker build efficiency by excluding unnecessary files and directories.Documentation