|
|
|
@@ -1,12 +1,13 @@
|
|
|
|
|
# Gitea Actions Workflow Architecture
|
|
|
|
|
|
|
|
|
|
This document describes the workflow architecture for version bumping and releases.
|
|
|
|
|
This document describes the workflow architecture for version bumping, testing, and releases.
|
|
|
|
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
|
|
|
|
The workflow architecture uses a two-step process:
|
|
|
|
|
1. **PR Workflow**: Analyzes commits and suggests bump type
|
|
|
|
|
2. **Release Workflow**: Bumps version, creates tags, and builds Docker images on merge
|
|
|
|
|
The workflow architecture uses a three-step process:
|
|
|
|
|
1. **PR Workflow**: Runs tests on PRs and analyzes commits for bump type
|
|
|
|
|
2. **Test Workflow**: Runs unit tests on all branch pushes (except version bumps)
|
|
|
|
|
3. **Release Workflow**: Bumps version, creates tags, builds Docker images, and deploys on main branch pushes
|
|
|
|
|
|
|
|
|
|
## Workflow Files
|
|
|
|
|
|
|
|
|
@@ -15,16 +16,36 @@ The workflow architecture uses a two-step process:
|
|
|
|
|
**Trigger**: Pull requests to `main` branch
|
|
|
|
|
|
|
|
|
|
**Purpose**:
|
|
|
|
|
- Run unit tests on every PR
|
|
|
|
|
- Run unit tests on every PR (fast feedback)
|
|
|
|
|
- Run acceptance tests with SQLite database
|
|
|
|
|
- Analyze commits to determine bump type (major/minor/patch)
|
|
|
|
|
- Comment the suggested bump type on the PR
|
|
|
|
|
|
|
|
|
|
**Test Execution**:
|
|
|
|
|
- **Unit Tests**: Run first, fast execution
|
|
|
|
|
- **Acceptance Tests**: Run after unit tests pass, uses SQLite database
|
|
|
|
|
- **Database**: SQLite with `DATABASE_URL=file:./prisma/ci.db`
|
|
|
|
|
- **Secrets**: Uses `BETTER_AUTH_SECRET` for authentication
|
|
|
|
|
|
|
|
|
|
**Bump Type Detection**:
|
|
|
|
|
- **Major**: Breaking changes detected (`BREAKING CHANGE` or `!:` in commit messages)
|
|
|
|
|
- **Minor**: Feature commits detected (`feat:` prefix)
|
|
|
|
|
- **Patch**: Default for fixes and other changes
|
|
|
|
|
|
|
|
|
|
### 2. `.gitea/workflows/release.yml` (Release Workflow)
|
|
|
|
|
### 2. `.gitea/workflows/test.yml` (Test Workflow)
|
|
|
|
|
|
|
|
|
|
**Trigger**: Pushes to any branch (including main)
|
|
|
|
|
|
|
|
|
|
**Purpose**:
|
|
|
|
|
- Run unit tests on all branch pushes
|
|
|
|
|
- Skip auto-generated version bump commits (handled by release workflow)
|
|
|
|
|
|
|
|
|
|
**Key Features**:
|
|
|
|
|
- Runs on all branches including main
|
|
|
|
|
- Skips commits with "chore: bump version" message
|
|
|
|
|
- Fast execution for quick feedback
|
|
|
|
|
|
|
|
|
|
### 3. `.gitea/workflows/release.yml` (Release Workflow)
|
|
|
|
|
|
|
|
|
|
**Trigger**: Pushes to `main` branch (after PR merge)
|
|
|
|
|
|
|
|
|
@@ -33,7 +54,7 @@ The workflow architecture uses a two-step process:
|
|
|
|
|
- Bump version in `package.json` and `CHANGELOG.md`
|
|
|
|
|
- Commit the version bump
|
|
|
|
|
- Create git tag for the release
|
|
|
|
|
- Run tests inside Docker container
|
|
|
|
|
- Run tests inside Docker container (with PostgreSQL)
|
|
|
|
|
- Build production Docker image
|
|
|
|
|
- Push images to registry
|
|
|
|
|
- Deploy to dev environment
|
|
|
|
@@ -42,6 +63,7 @@ The workflow architecture uses a two-step process:
|
|
|
|
|
- Skips commits that are auto-generated version bumps
|
|
|
|
|
- Uses `DOCKER_LOGIN` and `DOCKER_PASSWORD` secrets for registry auth
|
|
|
|
|
- Handles existing git tags gracefully
|
|
|
|
|
- Runs comprehensive tests in production-like environment
|
|
|
|
|
|
|
|
|
|
## Version Bump Logic
|
|
|
|
|
|
|
|
|
@@ -108,6 +130,25 @@ When a PR is merged to `main`:
|
|
|
|
|
- Creates tag v1.0.0
|
|
|
|
|
- Proceeds with build and deploy
|
|
|
|
|
|
|
|
|
|
## Database Configuration for CI
|
|
|
|
|
|
|
|
|
|
### SQLite for CI Acceptance Tests
|
|
|
|
|
- **Why SQLite**: No database server required, perfect for CI environments
|
|
|
|
|
- **Usage**: PR workflow runs acceptance tests with SQLite database
|
|
|
|
|
- **Configuration**: `DATABASE_PROVIDER=sqlite`, `DATABASE_URL=file:./prisma/ci.db`
|
|
|
|
|
- **Benefits**: Fast, isolated, no external dependencies
|
|
|
|
|
|
|
|
|
|
### PostgreSQL for Production
|
|
|
|
|
- **Usage**: Release workflow runs tests in Docker with PostgreSQL
|
|
|
|
|
- **Configuration**: Uses dummy PostgreSQL URL for Docker builds
|
|
|
|
|
- **Benefits**: Production-like environment, catches PostgreSQL-specific issues
|
|
|
|
|
|
|
|
|
|
### Database Provider Detection
|
|
|
|
|
The application automatically detects the database provider:
|
|
|
|
|
- `DATABASE_PROVIDER` environment variable (defaults to `sqlite`)
|
|
|
|
|
- `prisma.ts` conditionally uses PrismaPg adapter for PostgreSQL
|
|
|
|
|
- Better Auth configured with appropriate provider
|
|
|
|
|
|
|
|
|
|
## Benefits
|
|
|
|
|
|
|
|
|
|
1. **No CI Loops**: Version bump commits are detected and skipped
|
|
|
|
@@ -115,6 +156,8 @@ When a PR is merged to `main`:
|
|
|
|
|
3. **Semantic Versioning**: Automated adherence to semver rules
|
|
|
|
|
4. **Traceability**: Git tags and changelog reflect all changes
|
|
|
|
|
5. **Safe Releases**: Tests run before version bump and deployment
|
|
|
|
|
6. **Fast CI**: SQLite tests run quickly without database server setup
|
|
|
|
|
7. **Comprehensive Testing**: Both unit and acceptance tests in PR workflow
|
|
|
|
|
|
|
|
|
|
## Future Enhancements
|
|
|
|
|
|
|
|
|
|