* feat: add E2E testing infrastructure with fake GitHub, Playwright, and CI workflow - Add fake GitHub API server (tests/e2e/fake-github-server.ts) with management API for seeding test data - Add Playwright E2E test suite covering full mirror workflow: service health checks, user registration, config, sync, verify - Add Docker Compose for E2E Gitea instance - Add orchestrator script (run-e2e.sh) with cleanup - Add GitHub Actions workflow (e2e-tests.yml) with Gitea service container - Make GITHUB_API_URL configurable via env var for testing - Add npm scripts: test:e2e, test:e2e:ci, test:e2e:keep, test:e2e:cleanup * feat: add real git repos + backup config testing to E2E suite - Create programmatic test git repos (create-test-repos.ts) with real commits, branches (main, develop, feature/*), and tags (v1.0.0, v1.1.0) - Add git-server container to docker-compose serving bare repos via dumb HTTP protocol so Gitea can actually clone them - Update fake GitHub server to emit reachable clone_url fields pointing to the git-server container (configurable via GIT_SERVER_URL env var) - Add management endpoint POST /___mgmt/set-clone-url for runtime config - Update E2E spec with real mirroring verification: * Verify repos appear in Gitea with actual content * Check branches, tags, commits, file content * Verify 4/4 repos mirrored successfully - Add backup configuration test suite: * Enable/disable backupBeforeSync config * Toggle blockSyncOnBackupFailure * Trigger re-sync with backup enabled and verify activities * Verify config persistence across changes - Update CI workflow to use docker compose (not service containers) matching the local run-e2e.sh approach - Update cleanup.sh for git-repos directory and git-server port - All 22 tests passing with real git content verification * refactor: split E2E tests into focused files + add force-push tests Split the monolithic e2e.spec.ts (1335 lines) into 5 focused spec files and a shared helpers module: helpers.ts — constants, GiteaAPI, auth, saveConfig, utilities 01-health.spec.ts — service health checks (4 tests) 02-mirror-workflow.spec.ts — full first-mirror journey (8 tests) 03-backup.spec.ts — backup config toggling (6 tests) 04-force-push.spec.ts — force-push simulation & backup verification (9 tests) 05-sync-verification.spec.ts — dynamic repos, content integrity, reset (5 tests) The force-push tests are the critical addition: F0: Record original state (commit SHAs, file content) F1: Rewrite source repo history (simulate force-push) F2: Sync to Gitea WITHOUT backup F3: Verify data loss — LICENSE file gone, README overwritten F4: Restore source, re-mirror to clean state F5: Enable backup, force-push again, sync through app F6: Verify Gitea reflects the force-push F7: Verify backup system was invoked (snapshot activities logged) F8: Restore source repo for subsequent tests Also added to helpers.ts: - GiteaAPI.getBranch(), .getCommit(), .triggerMirrorSync() - getRepositoryIds(), triggerMirrorJobs(), triggerSyncRepo() All 32 tests passing. * Try to fix actions * Try to fix the other action * Add debug info to check why e2e action is failing * More debug info * Even more debug info * E2E fix attempt #1 * E2E fix attempt #2 * more debug again * E2E fix attempt #3 * E2E fix attempt #4 * Remove a bunch of debug info * Hopefully fix backup bug * Force backups to succeed
GitHub Workflows for Gitea Mirror
This directory contains GitHub Actions workflows that automate the build, test, and deployment processes for the Gitea Mirror application.
Workflow Overview
| Workflow | File | Purpose |
|---|---|---|
| Astro Build and Test | astro-build-test.yml |
Builds and tests the Astro application for all branches and PRs |
| Docker Build and Push | docker-build.yml |
Builds and pushes Docker images only for the main branch |
| Docker Security Scan | docker-scan.yml |
Scans Docker images for security vulnerabilities |
Workflow Details
Astro Build and Test (astro-build-test.yml)
This workflow runs on all branches and pull requests. It:
- Builds the Astro project
- Runs all tests
- Uploads build artifacts for potential use in other workflows
When it runs:
-
On push to any branch (except changes to README.md and docs)
-
On pull requests to any branch (except changes to README.md and docs)
-
Uses Bun for dependency installation
-
Caches dependencies to speed up builds
-
Uploads build artifacts for 7 days
Docker Build and Push (docker-build.yml)
This workflow builds Docker images on pushes and pull requests, and pushes to GitHub Container Registry (ghcr.io) when permissions allow (main/tags and same-repo PRs).
When it runs:
- On push to the main branch
- On tag creation (v*)
- On pull requests (build + scan; push only for same-repo PRs)
Key features:
- Builds multi-architecture images (amd64 and arm64)
- Pushes images for main/tags and same-repo PRs
- Skips registry push for fork PRs (avoids package write permission failures)
- Uses build caching to speed up builds
- Creates multiple tags for each image (latest, semver, sha)
Docker Security Scan (docker-scan.yml)
This workflow scans Docker images for security vulnerabilities using Trivy.
When it runs:
- On push to the main branch that affects Docker-related files
- Weekly on Sunday at midnight (scheduled)
Key features:
- Scans for critical and high severity vulnerabilities
- Fails the build if vulnerabilities are found
- Ignores unfixed vulnerabilities
CI/CD Pipeline Philosophy
Our CI/CD pipeline follows these principles:
- Fast feedback for developers: The Astro build and test workflow runs on all branches and PRs to provide quick feedback.
- Efficient resource usage: Docker images are only built when changes are merged to main, not for every PR.
- Security first: Regular security scanning ensures our Docker images are free from known vulnerabilities.
- Multi-architecture support: All Docker images are built for both amd64 and arm64 architectures.
Adding or Modifying Workflows
When adding or modifying workflows:
- Ensure the workflow follows the existing patterns
- Test the workflow on a branch before merging to main
- Update this README if you add a new workflow or significantly change an existing one
- Consider the impact on CI resources and build times
Troubleshooting
If a workflow fails:
- Check the workflow logs in the GitHub Actions tab
- Common issues include:
- Test failures
- Build errors
- Docker build issues
- Security vulnerabilities
For persistent issues, consider opening an issue in the repository.
Helm Test (helm-test.yml)
This workflow run on the main branch and pull requests. it:
- Run yamllint to keep the formating unified
- Run helm template with different value files