|
| 1 | +# CI/CD Workflows Documentation |
| 2 | + |
| 3 | +This document details the continuous integration and continuous deployment workflows for the L402 Server Example project. |
| 4 | + |
| 5 | +## CI Workflow |
| 6 | + |
| 7 | +The CI workflow runs on every push to the main branch and on pull requests targeting main. It consists of several jobs that run in sequence: |
| 8 | + |
| 9 | +### 1. Check |
| 10 | + |
| 11 | +Performs initial quality checks on the codebase: |
| 12 | + |
| 13 | +- **Code Format**: Ensures all code follows Rust formatting guidelines using `cargo fmt`. |
| 14 | +- **Linting**: Runs Clippy to catch common mistakes and enforce code quality. |
| 15 | +- **Compilation**: Verifies that the code compiles correctly with all features enabled. |
| 16 | + |
| 17 | +This job sets up a Redis service container for any checks that might need database access. |
| 18 | + |
| 19 | +### 2. Test |
| 20 | + |
| 21 | +Runs the full test suite: |
| 22 | + |
| 23 | +- **Unit Tests**: Tests individual components in isolation. |
| 24 | +- **Integration Tests**: Tests interactions between components. |
| 25 | +- **Code Coverage**: Generates coverage reports using cargo-tarpaulin. |
| 26 | + |
| 27 | +The test job depends on the check job passing successfully. It also uses a Redis service container for tests that require database functionality. |
| 28 | + |
| 29 | +### 3. Security Audit |
| 30 | + |
| 31 | +Performs security checks: |
| 32 | + |
| 33 | +- **Dependency Audit**: Scans dependencies for known vulnerabilities using cargo-audit. |
| 34 | + |
| 35 | +### 4. Build |
| 36 | + |
| 37 | +Builds the production artifacts: |
| 38 | + |
| 39 | +- **Release Binary**: Compiles the application in release mode. |
| 40 | +- **Artifact Upload**: Uploads the compiled binary as a job artifact. |
| 41 | + |
| 42 | +This job runs only if the check and test jobs pass successfully. |
| 43 | + |
| 44 | +### 5. Docker |
| 45 | + |
| 46 | +Builds the Docker image: |
| 47 | + |
| 48 | +- **Docker Build**: Creates the Docker image with the application. |
| 49 | +- **Caching**: Uses GitHub's cache for faster builds. |
| 50 | + |
| 51 | +This job only runs on the main branch and depends on the build job passing successfully. |
| 52 | + |
| 53 | +## Release Workflow |
| 54 | + |
| 55 | +The release workflow is triggered when a release is published on GitHub or manually with a specified tag. |
| 56 | + |
| 57 | +### 1. Release Build |
| 58 | + |
| 59 | +Creates release artifacts: |
| 60 | + |
| 61 | +- **Binary Build**: Compiles the application in release mode. |
| 62 | +- **Archive Creation**: Packages the binary with documentation, license, and configuration examples. |
| 63 | +- **Asset Upload**: Uploads the archive to the GitHub release. |
| 64 | + |
| 65 | +### 2. Docker Publish |
| 66 | + |
| 67 | +Publishes Docker images: |
| 68 | + |
| 69 | +- **Image Build**: Creates the Docker image with the application. |
| 70 | +- **Registry Push**: Pushes the image to GitHub Container Registry (ghcr.io). |
| 71 | +- **Tagging**: Tags the image with both the specific version and 'latest'. |
| 72 | + |
| 73 | +## GitHub Repository Settings |
| 74 | + |
| 75 | +To make the most of these workflows, ensure the repository has the following settings: |
| 76 | + |
| 77 | +1. **Branch Protection Rules** for the main branch: |
| 78 | + - Require status checks to pass before merging |
| 79 | + - Require branches to be up-to-date before merging |
| 80 | + |
| 81 | +2. **GitHub Packages** enabled for Docker image publishing |
| 82 | + |
| 83 | +3. **Workflow Permissions** set to allow: |
| 84 | + - Write access to packages (for Docker publishing) |
| 85 | + - Write access to contents (for release assets) |
0 commit comments