Archived all completed OpenSpec changes, created .gitignore, implemented Gitea CI/CD, updated frontend with professional styling and clickable IPs, and added application documentation.
This commit is contained in:
@@ -0,0 +1,47 @@
|
||||
## 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.
|
||||
@@ -0,0 +1,27 @@
|
||||
## Why
|
||||
|
||||
To automate the build and deployment process of the application, ensuring consistent and reliable releases. This also provides clear instructions for users to run the application, improving developer onboarding and operational efficiency.
|
||||
|
||||
## What Changes
|
||||
|
||||
- A new GitHub Actions workflow file will be added to the repository, configured to be compatible with Gitea Actions.
|
||||
- This workflow will automatically build Docker images for both the backend and frontend services upon code pushes to specific branches.
|
||||
- The built Docker images will be tagged and pushed to the internal Gitea package repository.
|
||||
- The workflow will utilize a self-hosted runner with the label "run".
|
||||
- New documentation will be created, detailing how to set up and run the application locally, including instructions for using Docker Compose.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `ci-cd-pipeline`: Provides automated continuous integration and continuous deployment for the application's Docker images.
|
||||
- `application-documentation`: Offers comprehensive instructions for setting up and running the application.
|
||||
|
||||
### Modified Capabilities
|
||||
- None
|
||||
|
||||
## Impact
|
||||
|
||||
- Automated and consistent build and push of Docker images to the Gitea package repository.
|
||||
- Streamlined deployment process and improved release reliability.
|
||||
- Enhanced developer experience through clear and accessible application documentation.
|
||||
- Requires a configured Gitea instance with a Docker package repository and a self-hosted runner with the specified label.
|
||||
@@ -0,0 +1,36 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Project README File
|
||||
The project SHALL include a `README.md` file in the project root.
|
||||
|
||||
#### Scenario: README file existence
|
||||
- **WHEN** the project repository is initialized or cloned
|
||||
- **THEN** a `README.md` file SHALL be present in the root directory.
|
||||
|
||||
### Requirement: Application Overview
|
||||
The `README.md` file SHALL provide a brief overview of the application's purpose and functionality.
|
||||
|
||||
#### Scenario: User reads README
|
||||
- **WHEN** a user reads the `README.md` file
|
||||
- **THEN** they SHALL understand the application's purpose.
|
||||
|
||||
### Requirement: Prerequisites for Running
|
||||
The `README.md` file SHALL list all necessary prerequisites for running the application.
|
||||
|
||||
#### Scenario: User prepares to run application
|
||||
- **WHEN** a user consults the `README.md` for setup
|
||||
- **THEN** they SHALL find a list of required software (e.g., Docker, Node.js/npm).
|
||||
|
||||
### Requirement: Local Run Instructions
|
||||
The `README.md` file SHALL provide step-by-step instructions for running the application locally using Docker Compose.
|
||||
|
||||
#### Scenario: User runs application locally
|
||||
- **WHEN** a user follows the `README.md` instructions for local setup
|
||||
- **THEN** they SHALL be able to successfully start the application using Docker Compose.
|
||||
|
||||
### Requirement: Service Access Instructions
|
||||
The `README.md` file SHALL provide instructions on how to access the frontend and backend services once they are running.
|
||||
|
||||
#### Scenario: User accesses running services
|
||||
- **WHEN** a user has started the application
|
||||
- **THEN** they SHALL find information on the URLs/ports to access the frontend and backend.
|
||||
@@ -0,0 +1,40 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Gitea Actions Workflow File
|
||||
The project SHALL include a Gitea Actions compatible workflow file for CI/CD.
|
||||
|
||||
#### Scenario: Workflow file existence
|
||||
- **WHEN** the project repository is initialized or cloned
|
||||
- **THEN** a workflow file SHALL be present in the `.gitea/workflows/` or `.github/workflows/` directory.
|
||||
|
||||
### Requirement: Docker Image Build Automation
|
||||
The CI/CD pipeline SHALL automatically build Docker images for the backend and frontend services.
|
||||
|
||||
#### Scenario: Code push to main branch
|
||||
- **WHEN** code is pushed to the `main` branch
|
||||
- **THEN** the backend Docker image SHALL be built.
|
||||
- **AND** the frontend Docker image SHALL be built.
|
||||
|
||||
### Requirement: Docker Image Tagging
|
||||
The built Docker images SHALL be tagged with `latest` and the short commit SHA.
|
||||
|
||||
#### Scenario: Image build completion
|
||||
- **WHEN** a Docker image is successfully built
|
||||
- **THEN** the image SHALL be tagged with `latest`.
|
||||
- **AND** the image SHALL be tagged with the short commit SHA.
|
||||
|
||||
### Requirement: Docker Image Push to Gitea Registry
|
||||
The built Docker images SHALL be pushed to the internal Gitea package registry.
|
||||
|
||||
#### Scenario: Image build and tagging completion
|
||||
- **WHEN** Docker images are successfully built and tagged
|
||||
- **THEN** the backend image SHALL be pushed to the Gitea package registry.
|
||||
- **AND** the frontend image SHALL be pushed to the Gitea package registry.
|
||||
|
||||
### Requirement: Self-Hosted Runner Usage
|
||||
The CI/CD workflow SHALL utilize a self-hosted runner with the label "run".
|
||||
|
||||
#### Scenario: Workflow execution
|
||||
- **WHEN** the CI/CD workflow is executed
|
||||
- **THEN** it SHALL run on a self-hosted runner.
|
||||
- **AND** the self-hosted runner SHALL have the label "run".
|
||||
20
openspec/changes/archive/2026-03-27-add-gitea-ci-cd/tasks.md
Normal file
20
openspec/changes/archive/2026-03-27-add-gitea-ci-cd/tasks.md
Normal file
@@ -0,0 +1,20 @@
|
||||
## 1. CI/CD Workflow Implementation
|
||||
|
||||
- [x] 1.1 Create the CI/CD workflow file at `.github/workflows/ci-cd.yml`.
|
||||
- [x] 1.2 Configure the workflow to trigger on `push` events to the `main` branch.
|
||||
- [x] 1.3 Define a job that runs on a self-hosted runner with the label "run".
|
||||
- [x] 1.4 Add steps to checkout the repository code.
|
||||
- [x] 1.5 Add steps to build the backend Docker image.
|
||||
- [x] 1.6 Add steps to build the frontend Docker image.
|
||||
- [x] 1.7 Add steps to tag the built images with `latest` and the short commit SHA.
|
||||
- [x] 1.8 Add steps to log in to the Gitea Docker package registry using secrets.
|
||||
- [x] 1.9 Add steps to push the backend Docker image to the Gitea registry.
|
||||
- [x] 1.10 Add steps to push the frontend Docker image to the Gitea registry.
|
||||
|
||||
## 2. Documentation Creation
|
||||
|
||||
- [x] 2.1 Create or update the `README.md` file in the project root.
|
||||
- [x] 2.2 Add a brief application overview to `README.md`.
|
||||
- [x] 2.3 Add a list of prerequisites for running the application to `README.md`.
|
||||
- [x] 2.4 Add step-by-step instructions for running the application locally using Docker Compose to `README.md`.
|
||||
- [x] 2.5 Add instructions on how to access the frontend and backend services (URLs/ports) to `README.md`.
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-03-27
|
||||
Reference in New Issue
Block a user