RayLabsHQ/gitea-mirror
1
0
Fork 0
mirror of https://github.com/RayLabsHQ/gitea-mirror.git synced 2026-10-09 17:01:53 +02:00
Code Issues Packages Projects Releases 5 Wiki Activity
Files
3df3fa577ea116dd980949cec2a537d12b2f7b83
gitea-mirror/.github/workflows
T
History
ARUNAVO RAYandGitHub 3df3fa577e fix(ci): stop main builds from overwriting the latest image tag (#431) 
A merge and the release bump that follows it land on main seconds apart.
Both triggered the Docker workflow and both pushed latest, and on v3.36.1
the older build finished last, so latest carried 3.36.0 until the weekly
rebuild replaced it (#425).

The workflow now runs one build per ref at a time, cancelling superseded
branch builds but never a tag build. The latest tag is only pushed by a
stable release tag build, main builds push edge and the short sha, and
Docker Scout scans the digest the run just pushed instead of whatever
latest pointed at.
2026-09-16 07:31:45 +05:30
..
astro-build-test.yml
ci: bump bun 1.3.10/1.3.12 → 1.3.13 across CI and runtime
2026-04-22 08:39:37 +05:30
docker-build.yml
fix(ci): stop main builds from overwriting the latest image tag (#431)
2026-09-16 07:31:45 +05:30
e2e-tests.yml
fix(sso): repair SSO login bounce + migrate to @better-auth/oauth-provider (#307)
2026-06-02 11:40:54 +05:30
helm-test.yml
ci: increase workflow timeouts to 25m and upgrade CodeQL Action to v4
2026-03-06 08:55:11 +05:30
nix-build.yml
ci(nix): make the bun.nix drift check blocking
2026-08-01 10:08:31 +05:30
README.md
fix(ci): skip Docker Scout on fork PRs and add a Trivy scan for every PR (#369)
2026-08-24 07:52:41 +05:30

README.md

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, Push & Security Scan docker-build.yml Builds, scans, and pushes Docker images

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, Push & Security Scan (docker-build.yml)

This workflow builds Docker images on pushes and pull requests, scans them, 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)
  • Weekly on Sunday at midnight (scheduled security scan)

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)
  • Auto-syncs package.json version from v* tags during release builds
  • Validates release tags use semver format before building
  • After tag builds succeed, writes the same version back to main/package.json

Security scanning:

  • Docker Scout runs on main/tag pushes, the weekly schedule, and same-repo PRs. It needs the DOCKERHUB_USERNAME / DOCKERHUB_TOKEN secrets, posts a PR comment, and uploads SARIF to the Security tab.
  • Trivy runs on every PR, including forks. It needs no credentials and writes critical/high (fixable) findings to the job summary.
  • Fork PRs cannot use Docker Scout because GitHub never exposes repository secrets to them. Do not "fix" that with pull_request_target; it would run untrusted PR code with the secrets available.
  • Both scanners are informational and do not fail the build.

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 built for every PR so they can be scanned, but only pushed for main, tags, and same-repo PRs.
  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
Reference in New Issue View Git Blame Copy Permalink