5aa0f3260d
* fix(nix): enable sandboxed builds with bun2nix The Nix package was broken on Linux because `bun install` requires network access, which is blocked by Nix sandboxing (enabled by default on Linux). This switches to bun2nix for dependency management: - Add bun2nix flake input to pre-fetch all npm dependencies - Generate bun.nix lockfile for reproducible dependency resolution - Copy bun cache to writable location during build to avoid EACCES errors from bunx writing to the read-only Nix store - Add nanoid as an explicit dependency (was imported directly but only available as a transitive dep, which breaks with isolated linker) - Update CI workflow to perform a full sandboxed build - Add bun2nix to devShell for easy lockfile regeneration Closes #197 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(nix): create writable workdir for database access The app uses process.cwd()/data for the database path, but when running from the Nix store the cwd is read-only. Create a writable working directory with symlinks to app files and a real data directory. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
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