This page documents the automation infrastructure for building, packaging, and distributing Certimate. The project uses GitHub Actions for CI/CD, GoReleaser for multi-platform compilation, and Docker for containerized deployment.
Certimate is distributed as a single binary containing both the Go backend and the embedded React frontend. The build process requires a two-step approach: building the UI assets and then compiling the Go binary with those assets embedded via Go's embed package.
The project uses .goreleaser.yml to automate the creation of release archives and checksums for manual or automated distribution.
-trimpath to remove local file system paths from the binary and -ldflags="-s -w" to strip symbol tables and debug information for smaller binaries. .goreleaser.yml15-17github.com/certimate-go/certimate.Version using the {{ .Version }} template variable during the build. .goreleaser.yml18zip archives along with the LICENSE, README.md, and CHANGELOG.md files. .goreleaser.yml41-48amd64, arm64, and arm (v7). It specifically ignores windows/arm and darwin/arm (v7) combinations. .goreleaser.yml23-34The Makefile provides standardized commands for local development and cross-platform builds.
all / build: Compiles the binary for 6 combinations of OS/Arch: linux/amd64, linux/arm64, darwin/amd64, darwin/arm64, windows/amd64, and windows/arm64. Makefile15-24local.run: A development helper that fetches dependencies (go mod vendor), builds the UI (npm run build), and starts the server on port 8090 using go run main.go serve. Makefile39-40| OS | Architectures | CGO |
|---|---|---|
| Linux | amd64, arm64, armv7 | Disabled (0) |
| macOS | amd64, arm64 | Disabled (0) |
| Windows | amd64, arm64, 386 | Disabled (0) |
Sources: .goreleaser.yml1-61 .github/workflows/release.yml57-153 Makefile1-40
The CI/CD pipeline is split into several specialized workflows to handle releases, container image updates, and repository maintenance.
release.yml)Triggered when a tag matching v[0-9]* is pushed to the repository. .github/workflows/release.yml3-6
npm ci and npm run build within the ./ui directory and uploads the resulting ./ui/dist as a GitHub Action artifact. .github/workflows/release.yml9-33ui-build artifact and compile binaries for their respective platforms. It uses a loop to iterate through architectures (e.g., amd64, arm64, armv7). .github/workflows/release.yml35-161LICENSE, README.md, and CHANGELOG.md, generates a checksums.txt file using sha256sum, and creates a draft GitHub Release. .github/workflows/release.yml162-221Certimate maintains two separate Docker image pipelines:
push_docker_image.yml): Triggered by semantic version tags (e.g., v1.0.0). It excludes pre-release tags like alpha, beta, or rc. .github/workflows/push_docker_image.yml3-9push_docker_image_next.yml): Triggered by pre-release tags (alpha, beta, rc) and explicitly tags the resulting image as next. .github/workflows/push_docker_image_next.yml3-15Both workflows push multi-platform images (linux/amd64, linux/arm64, linux/arm/v7) to both Docker Hub (certimate/certimate) and Alibaba Cloud Container Registry. .github/workflows/push_docker_image.yml99-107 .github/workflows/push_docker_image_next.yml98-106
gh_pr_label.yml)Automatically labels new or reopened pull requests targeting main or next branches with pr: waiting for review using github.rest.issues.addLabels. .github/workflows/gh_pr_label.yml1-32
The following diagram illustrates how code moves from the repository to a published release, mapping GitHub Action jobs to their respective output entities.
Release Asset Flow
Sources: .github/workflows/release.yml1-221 .github/workflows/gh_pr_label.yml1-32
Dockerfile: A three-stage build used for local or manual builds.
webui-builder): Builds the frontend using node:24-alpine. Dockerfile1-7server-builder): Copies UI assets from the first stage and builds the Go binary with CGO_ENABLED=0. Dockerfile11-18alpine:latest as the runtime environment and sets the entrypoint to ./certimate serve --http 0.0.0.0:8090. Dockerfile21-24Dockerfile_gh: Optimized for GitHub Actions. It skips the Node.js build stage because the workflow provides the pre-built ui/dist artifact, significantly reducing build time on GitHub runners. It uses golang:1.25-alpine for the server builder. Dockerfile_gh5-17A standard docker-compose.yml is provided for quick deployment. It maps port 8090 and persists data in a local ./data directory, which is mapped to the application's internal database path (/app/pb_data). It also maps /etc/localtime and /etc/timezone to ensure correct scheduling. docker/docker-compose.yml1-13
Sources: Dockerfile1-25 Dockerfile_gh1-17 docker/docker-compose.yml1-13
To support users in regions with limited access to GitHub, Certimate maintains an automated mirror on Gitee.
release_sync_gitee.yml)A manual workflow (workflow_dispatch) that triggers a Python script to synchronize GitHub releases to Gitee using a GITEE_TOKEN stored in repository secrets. It uses Python 3.13. .github/workflows/release_sync_gitee.yml1-29
release_sync_gitee.py)This script automates the mirroring process via the Gitee API.
get_github_stable_release(): Fetches the latest non-prerelease from the GitHub API, filtering out versions containing "alpha", "beta", "rc", "preview", "test", or "unstable". .github/workflows/release_sync_gitee.py53-75create_gitee_release(): Creates a new release on Gitee with a temporary "Syncing..." marker (SYNC_MARKER). .github/workflows/release_sync_gitee.py140-156delete_gitee_release(): Cleans up existing releases and their attachments on Gitee before re-syncing to ensure consistency. .github/workflows/release_sync_gitee.py103-138request.urlretrieve and uploads them to Gitee using multipart/form-data with a custom boundary. .github/workflows/release_sync_gitee.py164-207Gitee Sync Logic
Sources: .github/workflows/release_sync_gitee.yml1-29 .github/workflows/release_sync_gitee.py1-207
Refresh this wiki
This wiki was recently refreshed. Please wait 7 days to refresh again.