Files
gitea-mirror/.github/workflows
Xyndra 2e00a610cb Add E2E testing (#201)
* 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
2026-03-01 07:35:13 +05:30
..
2026-02-24 08:46:05 +05:30
2026-03-01 07:35:13 +05:30
2026-02-24 08:46:05 +05:30

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:

  1. Fast feedback for developers: The Astro build and test workflow runs on all branches and PRs to provide quick feedback.
  2. Efficient resource usage: Docker images are only built when changes are merged to main, not for every PR.
  3. Security first: Regular security scanning ensures our Docker images are free from known vulnerabilities.
  4. Multi-architecture support: All Docker images are built for both amd64 and arm64 architectures.

Adding or Modifying Workflows

When adding or modifying workflows:

  1. Ensure the workflow follows the existing patterns
  2. Test the workflow on a branch before merging to main
  3. Update this README if you add a new workflow or significantly change an existing one
  4. Consider the impact on CI resources and build times

Troubleshooting

If a workflow fails:

  1. Check the workflow logs in the GitHub Actions tab
  2. 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