48 lines
3.3 KiB
Markdown
48 lines
3.3 KiB
Markdown
## Context
|
|
|
|
The current project lacks an automated Continuous Integration/Continuous Deployment (CI/CD) pipeline for building and pushing Docker images. This manual process can lead to inconsistencies and delays in development and deployment. Additionally, comprehensive documentation for setting up and running the application is missing, which can hinder new developer onboarding and general usability.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
- Implement a robust CI/CD pipeline using GitHub Actions (compatible with Gitea Actions) to automate the building and pushing of Docker images for both backend and frontend services.
|
|
- Ensure that Docker images are correctly tagged and pushed to the internal Gitea package repository.
|
|
- Provide clear, concise, and up-to-date documentation for running the application locally, including instructions for using Docker Compose.
|
|
|
|
**Non-Goals:**
|
|
- This design does not cover automated deployment to a production environment; it focuses solely on image building and pushing to the registry.
|
|
- Automated testing within the CI/CD pipeline is out of scope for this change.
|
|
- Advanced CI/CD features such as automated rollback strategies or complex deployment orchestrations are not included.
|
|
|
|
## Decisions
|
|
|
|
1. **CI/CD Workflow File**:
|
|
- A new workflow file (`.gitea/workflows/ci-cd.yml` or `.github/workflows/ci-cd.yml` for Gitea compatibility) will be created.
|
|
- The workflow will be triggered on `push` events to the `main` branch.
|
|
- It will use a self-hosted runner with the label `run`.
|
|
- **Build Process**:
|
|
- Docker images for both `backend` and `frontend` services will be built.
|
|
- Images will be tagged with `latest` and the short commit SHA.
|
|
- **Push Process**:
|
|
- Built images will be pushed to the Gitea internal Docker package registry.
|
|
- Authentication to the Gitea registry will be handled using Gitea secrets (e.g., `GITEA_USERNAME`, `GITEA_PASSWORD` or `GITEA_TOKEN`).
|
|
|
|
2. **Application Documentation**:
|
|
- A `README.md` file will be created or updated in the project root.
|
|
- The documentation will include:
|
|
- A brief overview of the application.
|
|
- Prerequisites for running the application (Docker, Node.js/npm for local dev).
|
|
- Step-by-step instructions for running the application locally using `docker-compose`.
|
|
- Instructions for accessing the frontend and backend services once running.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- **[Risk]** Gitea Actions compatibility: While Gitea Actions aim for GitHub Actions compatibility, subtle differences might exist.
|
|
- **Mitigation**: Thorough testing of the workflow on the target Gitea instance will be performed.
|
|
- **[Risk]** Security of Gitea credentials: Storing credentials for registry access.
|
|
- **Mitigation**: Gitea's built-in secrets management will be utilized to store sensitive information securely.
|
|
- **[Risk]** Documentation becoming outdated: Manual updates to documentation can lead to inconsistencies.
|
|
- **Mitigation**: Keep the documentation concise and focused on essential setup steps, making it easier to maintain.
|
|
- **[Risk]** Self-hosted runner availability: The CI/CD pipeline relies on a self-hosted runner being available and correctly configured.
|
|
- **Mitigation**: Clear instructions for setting up and maintaining the self-hosted runner will be assumed to be in place.
|