73 bug deploy pipeline issues#74
Conversation
- Updated the GitHub Actions workflow to build and deploy from any branch, allowing for more flexible deployments. - Added support for tagging images with both version and short SHA for better traceability. - Modified the deployment documentation to reflect changes in triggers and rollback procedures. - Adjusted the docker-compose configuration to utilize image digests for deployments.
- Simplified the GitHub Actions workflow for deploying the web app, improving clarity and efficiency. - Updated SSH actions to use `appleboy` for better handling of remote commands and file transfers. - Enhanced image tagging to include versioning and digest pinning for more reliable deployments. - Revised documentation to reflect changes in deployment triggers and SSH key management.
- Modified the GitHub Actions workflow to require a `tag` input for deployments, enhancing clarity and control over image versions. - Implemented logic to skip builds if the specified image tag already exists in GHCR, streamlining the deployment process. - Updated documentation to reflect changes in deployment triggers and rollback procedures, ensuring users understand the new workflow. - Adjusted the docker-compose configuration to utilize the specified image tag during deployment.
…a GitHub API - Updated the GitHub Actions workflow to fetch the `docker-compose.yml` file directly from the GitHub API, eliminating the need for a git checkout during deployment. - Enhanced logic to conditionally execute steps based on the existence of the image in GHCR, streamlining the deployment process. - Revised documentation to reflect the new method of fetching deployment assets and clarified the deployment steps.
… and documentation - Reorganized the GitHub Actions workflow to separate the build and deploy jobs, improving clarity and maintainability. - Updated job names and descriptions for better understanding of the workflow steps. - Enhanced logic to check for existing packages in GHCR, allowing for conditional execution of build steps. - Revised documentation to reflect the new job structure and clarify the deployment process.
- Updated the verification step in the GitHub Actions workflow to specifically check for the presence of the Dockerfile, enhancing error messaging for missing files. - Improved error handling to provide clearer feedback when the Dockerfile is not found, ensuring users can easily identify issues during deployment.
…irectory - Added a step in the GitHub Actions workflow to restore the `deploy/` directory from the default branch if it is missing at the specified ref, ensuring the Dockerfile is available for builds. - Updated documentation to clarify the handling of legacy tags and the restoration process for the `deploy/` directory during deployment.
- Modified the Dockerfile to dynamically select the appropriate build script based on the presence of `build:web` or `build` in `package.json`, ensuring compatibility with older tags. - Updated comments for clarity regarding the build process and script selection.
…ectory from default branch - Modified the GitHub Actions workflow to ensure the `deploy/` directory is always overlaid from the default branch, improving consistency in Docker packaging. - Updated documentation to clarify that packaging now consistently uses the latest `deploy/` files while retaining application sources from the checked-out tag.
…tHub API - Updated the GitHub Actions workflow to fetch the `deploy/Dockerfile` directly from the GitHub API, ensuring the latest version is used during builds and avoiding issues with stale files in shallow clones. - Revised documentation to clarify that the `deploy/Dockerfile` is now consistently loaded from the default branch, improving the reliability of the deployment process.
- Introduced a new `build:ci` script in `package.json` to standardize the build process for CI environments. - Updated the `Dockerfile` to utilize the new `build:ci` script, ensuring consistent builds across different environments. - Revised documentation to reflect the change in the build command used during deployment, enhancing clarity for users.
… logic - Changed the build command in `package.json` to use `npm run build:ci` for consistency in CI environments. - Enhanced the `Dockerfile` to dynamically select the appropriate build command based on the presence of `build:ci` or `build:web`, ensuring compatibility with various package.json configurations. - Updated comments in the Dockerfile for improved clarity regarding the build process.
…roved consistency - Changed the build command in `package.json` to use `bun run build:web`, aligning with the new build process. - Updated the `Dockerfile` to directly run `npm run build:web`, simplifying the build logic. - Revised documentation to reflect the updated build command used during deployment, ensuring clarity for users.
- Changed the base image in the Dockerfile from `oven/bun:1` to `node:22-alpine` for improved compatibility and performance. - Updated `package-lock.json` to include new dependencies such as `winston`, `@colors/colors`, and others, ensuring the project has the latest required packages for development and production. - Ensured that the installation command in the Dockerfile uses `npm install` for consistency with the updated environment.
- Changed the build command in `package.json` from `bun run build:web` to `npm run build:web`, ensuring alignment with the current build process and improving compatibility across environments.
- Reordered commands in the Dockerfile to first copy application files and then install dependencies, enhancing build efficiency. - Updated the build command to use `npm run build` for consistency with the latest package.json configuration, ensuring a smoother deployment process.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis pull request transitions the web deployment pipeline from Bun to Node/npm, replaces the automatic tag-push trigger with manual Changes
Sequence DiagramsequenceDiagram
actor User
participant GitHub as GitHub API
participant Runner as GitHub Runner
participant Registry as GHCR Registry
participant Server as Remote Server
User->>GitHub: Trigger workflow_dispatch with tag
GitHub->>Runner: Start build-package job
Runner->>Registry: Check if image:tag exists
alt Image not found
Runner->>GitHub: Fetch deploy/Dockerfile (API)
GitHub-->>Runner: Dockerfile content
Runner->>Runner: Build Docker image
Runner->>Registry: Push image:tag, image:sha-*, image:latest
Registry-->>Runner: Image pushed
else Image exists
Runner->>Runner: Skip build, resolve ref
end
Runner->>GitHub: Start deploy job
Runner->>GitHub: Fetch deploy/docker-compose.yml (API)
GitHub-->>Runner: docker-compose.yml content
Runner->>Runner: Prepare SSH connection
Runner->>Server: SCP upload docker-compose.yml to ~/pengine/
Server-->>Runner: File uploaded
Runner->>Server: SSH execute docker login
Server-->>Runner: Logged in
Runner->>Server: SSH execute docker compose pull
Server-->>Runner: Images pulled
Runner->>Server: SSH execute docker compose up -d
Server-->>Runner: Services started
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary by CodeRabbit
Chores
Documentation