Simplified Single GitHub Actions CI/CD File (Updated)
This is a practical build-up guide for creating one large ci.yml that is still readable, maintainable, and tailored to real repositories. Note that if this is provided to a repo with a pipeline already in place it’s generally an upgrade request. The resulting pipeline should be bespoke to each repo, but consistently in approach, logic, parts, etc.
The target outcome:
- One workflow file handles push, PR open/update, PR close, tags, release publish, manual dispatch, and monthly/nightly schedules.
- It supports mixed repos: Go, Node, Dart, Flutter, Qt/C++, classic C/Makefile, and Dockerized components.
- It can run in public mode (broader checks) or private mode (cost-controlled), while keeping default test runners Ubuntu unless cross-OS coverage is explicitly needed.
- It includes autofix PR creation + cleanup, security checks, artifact fan-out, and release lanes.
- It accounts for packaging outputs beyond standard app bundles, including source Debian and source RPM pipeline hooks.
The point is not tiny YAML. The point is one intelligent CI/CD platform per repo.
Before the workflow body, add a top-of-file pointer comment so agents and humans know where the generation rules live:
1# Agent rules for generation:
2# https://arran4.github.io/blog/post/2026/028-simplified-github-ci-updated/ (or whatever URL was provided. In this case it will be the end url for this file)
3# Built using this post as a reference/guide.
4name: CI/CD
Why one file (when multiple files are common)
Multiple files can work, but they drift over time:
- duplicated setup steps,
- inconsistent event triggers,
- fragmented release logic,
- duplicated policy logic for private/public repos.
A single file gives one policy and one dependency graph. You can still keep complexity sane by:
- sectioned jobs,
- capability outputs,
- profile outputs,
- event routing,
- reusable local scripts/config files.
Non-negotiable design rules
- Event routing first (avoid accidental duplicate work).
- Project-type decisions should mostly be install/template-time (human comments + toggles), with lightweight runtime detection as a safety net.
- Repo visibility is auto-detected (
github.event.repository.private) rather than manually toggled. - Public repos run broader checks by default; private repos are conservative unless manual mode asks for full.
- Autofix lanes are language-aware (go fmt/go fix, dart format, flutter format, prettier, etc).
- Release lanes are split (GoReleaser, container release, source package release).
- Monthly maintenance exists by default.
- Difficulty gating based on success of others.
Always verify GitHub Action major versions
Always check externally what the latest major release of a GitHub Action is and use that. Ignore what you feel is right. You must go to the release page and check. For example:
| Action | URL | Example Latest (as of writing) |
|---|---|---|
| checkout | https://github.com/actions/checkout/releases | v4 |
| setup-go | https://github.com/actions/setup-go/releases | v5 |
| setup-node | https://github.com/actions/setup-node/releases | v4 |
| golangci-lint-action | https://github.com/golangci/golangci-lint-action/releases | v6 |
Always use this logic when generating workflows.
Step 1: Triggers and modes (copy/paste)
This event model supports normal validation, releases, and cleanup lifecycle.
1name: CI/CD
2
3on:
4 push:
5 # We know the repo so the trunk branch should be filtered down / pre selected
6 branches: [main, master]
7 # semantic version tags + rc/beta snapshots
8 tags:
9 - 'v*'
10 - 'v*.*.*'
11 - 'v*.*.*-rc*'
12 - 'v*.*.*-beta*'
13 - 'v*.*.*-test*'
14 pull_request:
15 types: [opened, synchronize, reopened, ready_for_review]
16 branches: [main, master]
17 release:
18 types: [published]
19 workflow_dispatch:
20 inputs:
21 mode:
22 description: "Pipeline mode"
23 required: true
24 default: "lint-fix"
25 type: choice
26 options:
27 - lint-fix
28 - build
29 - release-major
30 - release-minor
31 - release-patch
32 - release-test
33 - release-rc
34 - release-alpha
35 - monthly-maintenance
36 release_version_override:
37 description: "Optional explicit release version (for example 2.4.0 or 2.4.0-rc.2)"
38 required: false
39 default: ""
40 type: string
41 allow_prs:
42 description: "Allow automation to open pull requests. Tools that fix like go fmt, go fix, etc, will use this. Also in some projects we do auto bumping of 'next version' this is for those situations too. On public projects that don't have existing failures or frequent failures, often I turn this on and off"
43 required: false
44 default: true
45 type: boolean
46 schedule:
47 # preferred heavy monthly run (quota reset strategy)
48 # Always target the 2nd of each month at 5am AEST ignore dst
49 - cron: '0 19 1 * *'
50 # optional nightly lightweight checks
51 - cron: '41 2 * * *'
Why this is better
- It handles PR close cleanup flows.
- It supports semantic tags and release candidates.
- It exposes explicit manual operational modes (
lint-fix,build, and explicit release modes (release-major,release-minor,release-patch,release-test,release-rc,release-alpha)). - It keeps manual-dispatch states valid by encoding release intent directly into
modevalues.
Step 1.5: Release mode routing (single-input design)
To avoid invalid manual-dispatch state combinations, keep a single release control surface in mode and one optional release_version_override.
1 prepare-release-tag:
2 name: Prepare release tag
3 needs: [route]
4 if: ${{ github.event_name == 'workflow_dispatch' && startsWith(inputs.mode, 'release-') }}
5 runs-on: ubuntu-latest
6 outputs:
7 release_tag: ${{ steps.tag.outputs.release_tag }}
8 next_version: ${{ steps.tag.outputs.next_version }}
9 steps:
10 - uses: actions/checkout@v4
11 with:
12 fetch-depth: 0
13 - name: Setup git-tag-inc
14 uses: arran4/git-tag-inc-action@v1
15 with:
16 mode: install
17 # Do not also run `go install github.com/arran4/git-tag-inc/...` in this job.
18 # Using both is redundant and has caused avoidable CI drift.
19 - id: tag
20 shell: bash
21 run: |
22 set -euo pipefail
23 git config --global user.name "github-actions[bot]"
24 git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com" # Note: you can get this ID using the GitHub API: curl -s https://api.github.com/users/github-actions%5Bbot%5D | jq .id
25 MODE="${{ inputs.mode }}"
26 OVERRIDE="${{ inputs.release_version_override }}"
27
28 if [[ -n "$OVERRIDE" ]]; then
29 # Accept "1.2.3" or "v1.2.3" override input.
30 OVERRIDE="${OVERRIDE#v}"
31 next_tag="v$OVERRIDE"
32 else
33 case "$MODE" in
34 release-major) level="major"; suffix="" ;;
35 release-minor) level="minor"; suffix="" ;;
36 release-patch) level="patch"; suffix="" ;;
37 release-test) level="patch"; suffix="test" ;;
38 release-rc) level="patch"; suffix="rc" ;;
39 release-alpha) level="patch"; suffix="alpha" ;;
40 *) echo "Unsupported release mode: $MODE"; exit 1 ;;
41 esac
42 if command -v git-tag-inc >/dev/null 2>&1; then
43 # git-tag-inc uses positional commands (patch/major/minor/test/rc...)
44 # and NOT flag forms like -patch.
45 level="${level#-}"
46 args=(-print-version-only "$level")
47 [[ -n "$suffix" ]] && args+=("$suffix")
48 next_tag=$(git-tag-inc "${args[@]}")
49 else
50 # Fallback implementation when git-tag-inc is not available.
51 git fetch --tags --force
52 latest=$(git tag -l 'v*' | sed 's/^v//' | sort -V | tail -n 1)
53 [[ -z "$latest" ]] && latest='0.0.0'
54
55 # Prefer npx semver if available (same pattern used in g2 fixes).
56 if command -v npx >/dev/null 2>&1; then
57 case "$level" in
58 major) bumped=$(npx --yes semver "$latest" -i major) ;;
59 minor) bumped=$(npx --yes semver "$latest" -i minor) ;;
60 *) bumped=$(npx --yes semver "$latest" -i patch) ;;
61 esac
62 next_tag="v${bumped}"
63 else
64 base="${latest%%-*}"
65 IFS='.' read -r maj min pat <<< "$base"
66 case "$level" in
67 major) maj=$((maj+1)); min=0; pat=0 ;;
68 minor) min=$((min+1)); pat=0 ;;
69 *) pat=$((pat+1)) ;;
70 esac
71 next_tag="v${maj}.${min}.${pat}"
72 fi
73
74 if [[ -n "$suffix" ]]; then
75 next_tag="${next_tag}-${suffix}.1"
76 fi
77 fi
78 fi
79
80 # Tagging safety guards to avoid duplicate/invalid release states.
81 [[ "$next_tag" =~ ^v[0-9]+\.[0-9]+\.[0-9]+([-.][0-9A-Za-z.]+)?$ ]] || {
82 echo "Invalid tag format: $next_tag" >&2
83 exit 1
84 }
85 git fetch --tags --force
86 if git rev-parse "$next_tag" >/dev/null 2>&1; then
87 echo "Tag already exists: $next_tag" >&2
88 echo "Choose a new mode or set release_version_override." >&2
89 exit 1
90 fi
91
92 echo "release_tag=$next_tag" >> "$GITHUB_OUTPUT"
93 clean_tag="${next_tag#v}"; clean_tag="${clean_tag%%-*}"
94 IFS='.' read -r maj min pat <<< "$clean_tag"
95 echo "next_version=${maj:-0}.${min:-0}.$(( ${pat:-0} + 1 ))-SNAPSHOT" >> "$GITHUB_OUTPUT"
With this approach, snapshot/prerelease is inferred from the selected release mode and tag suffix, not from separate toggles. It also fixes common tagging issues by normalizing override input (v prefix optional), validating tag shape, hard-failing on existing tags before publish jobs run, and reminding you to fetch tags before version math. It explicitly installs git-tag-inc via arran4/git-tag-inc-action@v1 (mode: install) and includes fallback bump paths (npx semver, then pure shell semver math) if the binary is not found. Do not double-install with a separate manual go install in the same job. Use git-tag-inc -print-version-only <major|minor|patch> [test|rc|alpha] positional arguments to avoid the recurring argument-format mistake. Never use -patch/-major/-minor as flags; those are invalid. Also configure git user/email in the job before running release tag tooling so CI tag operations do not fail on identity checks.
Language-specific Version Bumping
We should break up version bumping into individual components based on the languages in the repo, as different tools have different bump logic (e.g. pubspec.yaml has a different bump logic). Here are some quick copy/pasteables for each language:
Node (package.json):
1npm version patch --no-git-tag-version
Dart/Flutter (pubspec.yaml):
1PUBSPEC_VERSION=$(awk '/^version:/ {print $2}' pubspec.yaml)
2# increment logic ...
3sed -i "s/^version: .*/version: $NEW_VERSION/" pubspec.yaml
CMake (CMakeLists.txt):
1sed -i -E "s/(project\([^ ]+ VERSION )[^ )]+/\1$NEW_VERSION/" CMakeLists.txt
If your repository keeps a version in source files as well as tags (for example CMakeLists.txt, pubspec.yaml, package.json, or similar), compute the next version from the highest of source version and fetched tag version. That avoids the recurring failure mode where CI bumps from stale source state, reuses an already-published version, and collides on tag creation.
Step 2: Event routing to reduce duplicate runs
You noted a real issue: push + PR can duplicate work. We fix it with routing-first, state-aware if: behavior, but keep an important practical rule: lint/format/vet/test should still appear on PRs so reviewers get direct PR check visibility.
1concurrency:
2 # Keep this as a safety net, not the primary dedupe mechanism.
3 group: ${{ github.workflow }}-${{ github.event_name }}-${{ github.event.pull_request.number || github.ref }}
4 cancel-in-progress: true
5
6permissions:
7 # Remember to only provide permissions where necessary
8 contents: write
9 discussions: write
10 pull-requests: write
11 checks: write
12 packages: write
13 security-events: write
14
15jobs:
16 route:
17 name: Route event
18 runs-on: ubuntu-latest
19 outputs:
20 run_code_checks: ${{ steps.route.outputs.run_code_checks }}
21 run_pr_meta_checks: ${{ steps.route.outputs.run_pr_meta_checks }}
22 run_cleanup: ${{ steps.route.outputs.run_cleanup }}
23 run_release: ${{ steps.route.outputs.run_release }}
24 is_monthly: ${{ steps.route.outputs.is_monthly }}
25 is_nightly: ${{ steps.route.outputs.is_nightly }}
26 steps:
27 - id: route
28 shell: bash
29 run: |
30 set -euo pipefail
31
32 run_code_checks=false
33 run_pr_meta_checks=false
34 run_cleanup=false
35 run_release=false
36 is_monthly=false
37 is_nightly=false
38
39 case "${{ github.event_name }}" in
40 push)
41 run_code_checks=true
42 ;;
43 pull_request)
44 if [[ "${{ github.event.action }}" == "closed" ]]; then
45 # We need to reduce the number of reruns we are getting on "closed"
46 # I am not sure following closed is even necessary
47 # Skip execution if the PR was closed by being merged
48 if [[ "${{ github.event.pull_request.merged }}" == "true" ]]; then
49 exit 0
50 fi
51 run_cleanup=true
52 else
53 run_pr_meta_checks=true
54 # In practice, also run code checks on PRs so lint/fmt/vet/test
55 # show up directly in the PR UI. Use concurrency to collapse churn.
56 run_code_checks=true
57 fi
58 ;;
59 release)
60 run_release=true
61 ;;
62 workflow_dispatch)
63 run_code_checks=true
64 if [[ "${{ inputs.mode }}" == release-* ]]; then
65 run_release=true
66 fi
67 if [[ "${{ inputs.mode }}" == "monthly-maintenance" ]]; then
68 is_monthly=true
69 fi
70 if [[ "${{ inputs.mode }}" == "lint-fix" ]]; then
71 # Manual lint-fix acts as an on-demand nightly-style maintenance pass.
72 is_nightly=true
73 fi
74 ;;
75 schedule)
76 run_code_checks=true
77 if [[ "${{ github.event.schedule }}" == "17 3 1 * *" ]]; then
78 is_monthly=true
79 fi
80 if [[ "${{ github.event.schedule }}" == "41 2 * * *" ]]; then
81 is_nightly=true
82 fi
83 ;;
84 esac
85
86 echo "run_code_checks=$run_code_checks" >> "$GITHUB_OUTPUT"
87 echo "run_pr_meta_checks=$run_pr_meta_checks" >> "$GITHUB_OUTPUT"
88 echo "run_cleanup=$run_cleanup" >> "$GITHUB_OUTPUT"
89 echo "run_release=$run_release" >> "$GITHUB_OUTPUT"
90 echo "is_monthly=$is_monthly" >> "$GITHUB_OUTPUT"
91 echo "is_nightly=$is_nightly" >> "$GITHUB_OUTPUT"
High-confidence manual-dispatch router baseline
If you want a known-good baseline for manual dispatch semantics, use the same three-route-output shape proven in arran4/mlocate_explorer (run_code_checks, run_build, run_release) and then layer project-specific lanes onto it.
1 route:
2 name: Event Router
3 runs-on: ubuntu-latest
4 outputs:
5 run_code_checks: ${{ steps.decide.outputs.run_code_checks }}
6 run_build: ${{ steps.decide.outputs.run_build }}
7 run_release: ${{ steps.decide.outputs.run_release }}
8 steps:
9 - id: decide
10 shell: bash
11 run: |
12 set -euo pipefail
13 if [[ "${{ github.event_name }}" == "pull_request" && "${{ github.event.action }}" == "closed" ]]; then
14 # We need to reduce the number of reruns we are getting on "closed"
15 # I am not sure following closed is even necessary
16 if [[ "${{ github.event.pull_request.merged }}" == "true" ]]; then
17 exit 0
18 fi
19 echo "run_code_checks=false" >> "$GITHUB_OUTPUT"
20 echo "run_build=false" >> "$GITHUB_OUTPUT"
21 echo "run_release=false" >> "$GITHUB_OUTPUT"
22 exit 0
23 fi
24
25 echo "run_code_checks=true" >> "$GITHUB_OUTPUT"
26
27 if [[ "${{ github.ref }}" == refs/tags/* || ("${{ github.event_name }}" == "workflow_dispatch" && "${{ inputs.mode }}" != "lint-fix") ]]; then
28 echo "run_build=true" >> "$GITHUB_OUTPUT"
29 else
30 echo "run_build=false" >> "$GITHUB_OUTPUT"
31 fi
32
33 if [[ "${{ github.ref }}" == refs/tags/v* || ("${{ github.event_name }}" == "workflow_dispatch" && startsWith("${{ inputs.mode }}", "release-")) ]]; then
34 echo "run_release=true" >> "$GITHUB_OUTPUT"
35 else
36 echo "run_release=false" >> "$GITHUB_OUTPUT"
37 fi
This gives you predictable manual dispatch behavior: lint-fix runs checks only, build runs build lanes, and release-* runs build + release.
This gives explicit behavior control instead of relying only on cancellation.
Practical rule: keep code checks on both push and pull_request when you want lint/format/vet/test results visible in the PR itself. Let concurrency and event routing reduce churn, rather than hiding the checks from reviewers.
Clarification from a working real-world result (fork-qip style)
A practical setup that matches your intent closely uses these additional rules:
- Conditional cancellation for concurrency:
- cancel in-progress runs on non-main/non-tag refs,
- avoid cancelling
main,master, and tag builds.
- Dedicated
formatjob that always runs for Go repos during code-check events:- on manual
lint-fix, it opens an autofix PR, - otherwise it fails with diff output (forcing dev-side formatting).
- on manual
- Separate
go-lint,go-test, andgo-vetjobs for cleaner diagnostics and release gating. - Release job guarded with
!failure() && !cancelled()andneedsfan-in.
Copy/paste concurrency pattern from that style:
1concurrency:
2 group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
3 cancel-in-progress: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/master' && !startsWith(github.ref, 'refs/tags/') }}
This is stricter and often better than blanket cancel-in-progress: true in busy repos.
Step 3: Project profile decisions (config-time first, minimal runtime checks)
You are right that most tailoring should be done when installing the workflow. Do both:
- template comments/toggles for expected project types,
- runtime detection as guard rails.
1 language:
2 strict-casts: true
3
4linter:
5 rules:
6 - avoid_print
7 - prefer_single_quotes
Additional copy/paste config starters:
.golangci.yml
1run:
2 timeout: 5m
3
4linters:
5 enable:
6 - govet
7 - staticcheck
8 - errcheck
9 - ineffassign
10 - revive
.prettierrc.json
1{
2 "semi": false,
3 "singleQuote": true,
4 "printWidth": 100
5}
.clang-format
1BasedOnStyle: LLVM
2IndentWidth: 2
3ColumnLimit: 100
packaging/rpm/app.spec (source rpm compatible starter)
1Name: app
2Version: %{?version}%{!?version:0.0.0}
3Release: 1%{?dist}
4Summary: App summary
5License: MIT
6Source0: %{name}-%{version}.tar.gz
7
8%description
9App description.
10
11%prep
12%autosetup
13
14%build
15# build steps here
16
17%install
18mkdir -p %{buildroot}/usr/bin
19
20%files
21/usr/bin/*
22
23%changelog
24* Thu Mar 04 2026 CI Bot <ci@example.com> - %{version}-1
25- Automated source build
Step 5: Security jobs (automatic profile behavior)
1 gitleaks:
2 name: Secret scan
3 needs: [route]
4 if: ${{ needs.route.outputs.run_cleanup != 'true' && (needs.route.outputs.is_nightly == 'true' || needs.route.outputs.is_monthly == 'true') }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 with:
9 fetch-depth: 0
10 - uses: gitleaks/gitleaks-action@v2
11 env:
12 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
13
14 dependency-review:
15 name: Dependency review (public/full)
16 needs: [route]
17 if: ${{ github.event_name == 'pull_request' && github.event.action != 'closed' }}
18 runs-on: ubuntu-latest
19 steps:
20 - uses: actions/dependency-review-action@v4
Public repos can afford broader checks by default. Private repos keep monthly/full-mode heavy scans.
Leak check policy: run secret/leak scans as part of nightly/monthly maintenance only (including manual lint-fix maintenance dispatch).
Step 5.5: Java/Maven lane (from kagura-style repos)
If a repo has pom.xml, add this lane. It is useful for polyglot repos where Java packaging coexists with Go/Node/others.
1 java-build-test:
2 name: Java build/test
3 needs: [route]
4 if: ${{ needs.route.outputs.run_code_checks == 'true' && hashFiles('pom.xml') != '' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - uses: actions/setup-java@v4
9 with:
10 java-version: '11'
11 distribution: temurin
12 cache: maven
13 - run: mvn spotless:check
14 - run: mvn test -DskipITs=false
This mirrors the style in your referenced workflow and can be chained into release fan-in if Java artifacts are part of your release.
Step 5.6: Hugo Pages integration pattern
If the repository includes a Hugo docs/site directory (example: site/mydocs), add a Pages lane that builds and deploys docs on main/master, tag releases, and manual dispatch.
Deployment targets to note:
- GitHub Pages Action: Preferred over committing to a branch.
- GitHub Pages Branch: Preferred action if using legacy methods.
- Cloudflare: Preview builds need to be supported for Cloudflare deployments.
Key ideas from the referenced workflow:
- route-level
run_pagesoutput (separate from code-check/release output), - workflow permissions include
pages: writeandid-token: write, - split build and deploy jobs (
hugo-build->hugo-deploy), - deployment concurrency uses the
pagesgroup.
Route additions (copy/paste)
1permissions:
2 # Remember to only provide permissions where necessary
3 contents: write
4 pull-requests: write
5 checks: write
6 packages: write
7 security-events: write
8 pages: write
9 id-token: write
10
11jobs:
12 route:
13 outputs:
14 run_pages: ${{ steps.route.outputs.run_pages }}
15 steps:
16 - id: route
17 run: |
18 run_pages=false
19 if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
20 run_pages=true
21 elif [[ "${{ github.ref }}" == refs/tags/* || "${{ github.ref }}" == "refs/heads/main" || "${{ github.ref }}" == "refs/heads/master" ]]; then
22 run_pages=true
23 fi
24 echo "run_pages=$run_pages" >> "$GITHUB_OUTPUT"
25
26 hugo-build:
27 name: Build Hugo site
28 needs: [route]
29 if: ${{ needs.route.outputs.run_pages == 'true' }}
30 runs-on: ubuntu-latest
31 env:
32 HUGO_VERSION: ${{ inputs.hugo_version || '0.123.7' }}
33 steps:
34 - name: Install Hugo CLI
35 run: |
36 wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb
37 sudo dpkg -i ${{ runner.temp }}/hugo.deb
38 - name: Install Dart Sass
39 run: sudo snap install dart-sass
40 - uses: actions/checkout@v4
41 with:
42 submodules: recursive
43 - id: pages
44 uses: actions/configure-pages@v5
45 - name: Install Node dependencies
46 working-directory: ./site/mydocs
47 run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"
48 - name: Build with Hugo
49 working-directory: ./site/mydocs
50 env:
51 HUGO_ENVIRONMENT: production
52 HUGO_ENV: production
53 run: |
54 hugo --minify --baseURL "${{ steps.pages.outputs.base_url }}/"
55 - uses: actions/upload-pages-artifact@v3
56 with:
57 path: ./site/mydocs/public
58
59 hugo-deploy:
60 name: Deploy to GitHub Pages
61 needs: [route, hugo-build]
62 if: ${{ needs.route.outputs.run_pages == 'true' }}
63 runs-on: ubuntu-latest
64 concurrency:
65 group: pages
66 cancel-in-progress: false
67 environment:
68 name: github-pages
69 url: ${{ steps.deployment.outputs.page_url }}
70 steps:
71 - name: Deploy to GitHub Pages
72 id: deployment
73 uses: actions/deploy-pages@v4
This keeps docs/site deployment first-class without mixing it into language build jobs.
Step 6: Go lane (tests, lint, vet, release prep)
Use setup-go built-in caching instead of manual actions/cache.
1 # Requested baseline snippet (modern versions)
2 golangci:
3 name: lint
4 needs: [route]
5 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
6 runs-on: ubuntu-latest
7 steps:
8 - uses: actions/checkout@v5
9 - uses: actions/setup-go@v6
10 with:
11 go-version-file: go.main
12 - name: golangci-lint
13 uses: golangci/golangci-lint-action@v9
14 with:
15 version: latest
16
17 go-test:
18 name: Go lint/test (${{ matrix.os }})
19 needs: [route, golangci]
20 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
21 runs-on: ${{ matrix.os }}
22 strategy:
23 fail-fast: false
24 matrix:
25 # Cost-aware default: Ubuntu only.
26 # Add windows-latest/macos-latest only for true platform-specific behavior.
27 os: [ubuntu-latest]
28 steps:
29 - uses: actions/checkout@v4
30 - uses: actions/setup-go@v6
31 with:
32 go-version-file: go.main
33 cache: true
34 - name: Test
35 run: go test ./... -v
36
37 go-vet:
38 name: Go vet
39 needs: [route]
40 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
41 runs-on: ubuntu-latest
42 steps:
43 - uses: actions/checkout@v4
44 - uses: actions/setup-go@v6
45 with:
46 go-version-file: go.main
47 cache: true
48 - run: go vet ./...
49
50 go-fmt-pr:
51 name: go fmt -> PR (manual dispatch)
52 needs: [route]
53 if: ${{ github.event_name == 'workflow_dispatch' && inputs.mode == 'lint-fix' && inputs.allow_prs == true }}
54 runs-on: ubuntu-latest
55 steps:
56 - uses: actions/checkout@v4
57 - uses: actions/setup-go@v6
58 with:
59 go-version-file: go.main
60 - name: Run go fmt
61 run: go fmt ./...
62 - name: Create PR if go fmt changed files
63 env:
64 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
65 run: |
66 set -euo pipefail
67 git diff --quiet && { echo "No fmt changes"; exit 0; }
68 git config user.name "github-actions[bot]"
69 git config user.email "41898282+github-actions[bot]@users.noreply.github.com" # Note: you can get this ID using the GitHub API: curl -s https://api.github.com/users/github-actions%5Bbot%5D | jq .id
70 BRANCH="ci/gofmt/${{ github.run_id }}"
71 git checkout -b "$BRANCH"
72 git add -A
73 git commit -m "ci: go fmt"
74 git push origin "$BRANCH"
75 gh pr create --title "ci: go fmt" --body "Automated go fmt from manual dispatch." --base main --head "$BRANCH" --label "ci-autofix"
This separates lint, test, and vet while keeping a dedicated manual-dispatch go fmt -> PR path.
Recommended behavior (from your working result):
- Keep
formatas a required job in normal CI. - If
mode == lint-fix, auto-open PR with fixes. - Otherwise fail the job and print diff so formatting is corrected in source branches.
Optional cross-OS lane (only when it really matters):
1 go-cross-os-smoke:
2 name: Go cross-OS smoke (${{ matrix.os }})
3 needs: [route, golangci]
4 if: ${{ needs.route.outputs.run_code_checks == 'true' && (github.event_name == 'workflow_dispatch' && inputs.mode == 'build') }}
5 runs-on: ${{ matrix.os }}
6 strategy:
7 fail-fast: false
8 matrix:
9 os: [ubuntu-latest, windows-latest, macos-latest]
10 steps:
11 - uses: actions/checkout@v4
12 - uses: actions/setup-go@v6
13 with:
14 go-version-file: go.main
15 - run: go build ./...
Step 7: Node lane (tests, lint, source package + versioning integration)
1 node-lint-test:
2 name: Node lint/test
3 needs: [route]
4 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - uses: actions/setup-node@v4
9 with:
10 node-version: '22'
11 cache: 'npm'
12 - run: npm ci
13 - run: npm run lint --if-present
14 - run: npm test --if-present
15 - name: Build source npm package
16 run: npm pack --json > npm-pack-result.json
17
18 - uses: actions/upload-artifact@v4
19 with:
20 name: npm-source-package
21 retention-days: 1
22 path: |
23 *.tgz
24 npm-pack-result.json
Use this baseline with Step 7.5 below as the release/versioning extension for npm publish.
Step 7.5: Node/TS version automation (integrated publish path)
For npm packages, the tsobjectutils workflow has strong production ideas worth reusing:
- manual bump levels (
patch|minor|major|prerelease), - optional prerelease creation (
-next), - compute whether publish is allowed (
-nextcan skip public publish), - idempotent tag/release creation (
actions/github-scriptchecks if they already exist), - publish with correct npm dist-tag (
latestvsnext), - create a PR for the next development iteration version.
Copy/paste control snippet:
1on:
2 workflow_dispatch:
3 inputs:
4 level:
5 description: Version Bump Level
6 required: true
7 default: patch
8 type: choice
9 options: [patch, minor, major, prerelease]
10 create_prerelease:
11 description: Create as prerelease (e.g. -next.0)
12 required: false
13 default: false
14 type: boolean
15
16jobs:
17 version-and-release:
18 runs-on: ubuntu-latest
19 steps:
20 - uses: actions/checkout@v4
21 with:
22 fetch-depth: 0
23 - uses: actions/setup-node@v4
24 with:
25 node-version: '18'
26
27 - name: Manual Version Bump
28 if: github.event_name == 'workflow_dispatch'
29 run: |
30 LEVEL="${{ inputs.level }}"
31 CREATE_PRE="${{ inputs.create_prerelease }}"
32 if [ "$LEVEL" = "prerelease" ]; then
33 npm version prerelease --preid=next --no-git-tag-version
34 elif [ "$CREATE_PRE" = "true" ]; then
35 npm version pre$LEVEL --preid=next --no-git-tag-version
36 else
37 npm version $LEVEL --no-git-tag-version
38 fi
39
40 - name: Determine npm tag and prerelease state
41 id: versions
42 run: |
43 CURRENT_VERSION=$(node -p "require('./package.json').version")
44 if [[ "$CURRENT_VERSION" == *-* ]]; then
45 echo "npm_tag=next" >> "$GITHUB_OUTPUT"
46 echo "is_prerelease=true" >> "$GITHUB_OUTPUT"
47 else
48 echo "npm_tag=latest" >> "$GITHUB_OUTPUT"
49 echo "is_prerelease=false" >> "$GITHUB_OUTPUT"
50 fi
This pattern reduces accidental duplicate tags/releases and gives predictable npm channel behavior.
Step 8: Dart + Flutter lanes (including libraries)
You asked to include Dart libs and Flutter libs specifically, with analysis.
1 dart-analyze-test:
2 name: Dart analyze/test
3 needs: [route]
4 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - uses: dart-lang/setup-dart@v1
9 - run: dart --version
10 - run: dart pub get
11 - run: dart format --set-exit-if-changed .
12 - run: dart analyze
13 - run: dart test
14
15 flutter-analyze-test:
16 name: Flutter analyze/test (fast path)
17 needs: [route]
18 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
19 runs-on: ubuntu-latest
20 steps:
21 - uses: actions/checkout@v4
22 - uses: subosito/flutter-action@v2
23 with:
24 channel: stable
25 - run: flutter --version
26 - run: flutter pub get
27 - run: dart format --set-exit-if-changed .
28 - run: flutter analyze
29 - run: flutter test
30
31 flutter-format-pr:
32 name: Flutter format -> PR (manual lint-fix)
33 needs: [route]
34 if: ${{ github.event_name == 'workflow_dispatch' && inputs.mode == 'lint-fix' }}
35 runs-on: ubuntu-latest
36 steps:
37 - uses: actions/checkout@v4
38 - uses: subosito/flutter-action@v2
39 with:
40 channel: stable
41 - run: flutter pub get
42 - id: format
43 run: |
44 dart format .
45 if [[ -n $(git status --porcelain -- '*.dart') ]]; then
46 echo "changes=true" >> "$GITHUB_OUTPUT"
47 git status --porcelain -- '*.dart'
48 else
49 echo "changes=false" >> "$GITHUB_OUTPUT"
50 fi
51 - name: Open PR with formatting fixes
52 if: steps.format.outputs.changes == 'true' && inputs.allow_prs == true
53 uses: peter-evans/create-pull-request@v7
54 with:
55 token: ${{ secrets.GITHUB_TOKEN }}
56 commit-message: "style: apply dart format"
57 title: "style: apply dart format"
58 body: "Automated PR for Flutter/Dart formatting fixes."
59 branch: "automated/dart-format-${{ github.ref_name }}"
60 base: ${{ github.ref_name }}
61 delete-branch: true
62 - name: Fail if formatting drift exists
63 if: steps.format.outputs.changes == 'true'
64 run: |
65 echo "Formatting drift detected. Fix directly or merge the generated PR."
66 exit 1
67
68 flutter-build-artifacts:
69 name: Flutter build artifacts (release/monthly only)
70 needs: [route, flutter-analyze-test]
71 if: ${{ (needs.route.outputs.run_release == 'true' || needs.route.outputs.is_monthly == 'true' || (github.event_name == 'workflow_dispatch' && inputs.mode == 'build')) }}
72 runs-on: ubuntu-latest
73 steps:
74 - uses: actions/checkout@v4
75 - uses: subosito/flutter-action@v2
76 with:
77 channel: stable
78 - run: flutter pub get
79 - run: flutter build linux --release
80 - run: flutter build apk --release || true
81
82 - uses: actions/upload-artifact@v4
83 with:
84 name: flutter-release-bundles
85 retention-days: 1
86 path: |
87 build/linux/**
88 build/app/outputs/flutter-apk/*.apk
Fastforge note
Fastforge is optional. Keep it if you want it; remove it if you don’t. The key pattern is to keep release outputs available through independent lanes (flatpak, source packages, container artifacts, GoReleaser outputs) so your pipeline doesn’t depend on a single packaging tool.
Confidence note (tested manual dispatch)
The Flutter manual-dispatch pattern above is based on a working pipeline where mode=lint-fix plus allow_prs has been tested in practice (arran4/mlocate_explorer, commit 9ce9d36). Treat this as a higher-confidence baseline for Flutter than untested snippets, then add platform build lanes (Linux/Windows/macOS) only when your project actually needs cross-OS deliverables.
When you do add cross-OS Flutter builds, follow this same split:
- keep format/analyze/test as the fast Ubuntu path,
- gate expensive Linux/Windows/macOS artifact lanes behind
run_buildor release, - upload artifacts per platform and publish only from release-scoped jobs.
Dart release/version-sync pattern (from dartobjectutils)
For Dart-first repos, one practical pattern is:
- run
dart analyze/dart test, - on manual dispatch, compute the next version (
patch|minor|major|manual), - update
pubspec.yaml, commit, tag, push, - verify tag version matches
pubspec.yamland auto-fix with PR fallback when direct push fails.
Copy/paste release prep snippet:
1 dart-release-prep:
2 name: Dart release prep
3 if: ${{ github.event_name == 'workflow_dispatch' }}
4 runs-on: ubuntu-latest
5 steps:
6 - uses: actions/checkout@v4
7 with:
8 fetch-depth: 0
9 - uses: dart-lang/setup-dart@v1
10 - name: Compute version and tag
11 env:
12 INCREMENT: ${{ inputs.increment }}
13 MANUAL_VERSION_INPUT: ${{ inputs.manual_version }}
14 run: |
15 set -euo pipefail
16 PUBSPEC_VERSION=$(awk '/^version:/ {print $2}' pubspec.yaml)
17 git fetch --tags
18 HIGHEST_TAG=$(git tag -l "v*" | sed 's/^v//' | sort -V | tail -n 1)
19 [ -z "$HIGHEST_TAG" ] && HIGHEST_TAG="0.0.0"
20
21 CURRENT_VERSION=$(echo -e "$PUBSPEC_VERSION
22$HIGHEST_TAG" | sort -V | tail -n 1)
23
24 if [ "$INCREMENT" = "manual" ]; then
25 [ -z "$MANUAL_VERSION_INPUT" ] && { echo "manual_version required"; exit 1; }
26 NEW_VERSION="$MANUAL_VERSION_INPUT"
27 else
28 IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
29 case "$INCREMENT" in
30 major) NEW_VERSION="$((MAJOR+1)).0.0" ;;
31 minor) NEW_VERSION="$MAJOR.$((MINOR+1)).0" ;;
32 *) NEW_VERSION="$MAJOR.$MINOR.$((PATCH+1))" ;;
33 esac
34 fi
35
36 sed -i "s/^version: .*/version: $NEW_VERSION/" pubspec.yaml
37 git config user.name "github-actions[bot]"
38 git config user.email "41898282+github-actions[bot]@users.noreply.github.com" # Note: you can get this ID using the GitHub API: curl -s https://api.github.com/users/github-actions%5Bbot%5D | jq .id
39 git checkout -b "release/v$NEW_VERSION"
40 git add pubspec.yaml
41 git commit -m "Bump version to $NEW_VERSION"
42 git tag -f "v$NEW_VERSION"
43 git push -f origin "v$NEW_VERSION"
44 git push origin "release/v$NEW_VERSION"
Step 9: Qt/C++ and classic C lane
Include both Qt/CMake and Makefile detection paths.
1 cpp-qt-build-test:
2 name: Qt/C++ build
3 needs: [route]
4 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - run: sudo apt-get update
9 - run: sudo apt-get install -y cmake ninja-build build-essential qt6-base-dev qt6-tools-dev clang-format cppcheck
10 - name: Lint style and static checks
11 run: |
12 find . \( -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.hpp' \) -print0 | xargs -0 -r clang-format --dry-run --Werror
13 cppcheck --enable=warning,style,performance,portability --error-exitcode=1 .
14 - run: cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release
15 - run: cmake --build build --parallel
16 - run: ctest --test-dir build --output-on-failure
17
18 c-make-build-test:
19 name: Classic C Makefile build
20 needs: [route]
21 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
22 runs-on: ubuntu-latest
23 steps:
24 - uses: actions/checkout@v4
25 - run: make -j"$(nproc)" all
26 - run: make test || true
Step 10: Integrated autofix + PR automation lane
You wanted this wired to real formatters and branch-name guessable behavior.
1 autofix:
2 name: Auto-format and open PR
3 needs: [route]
4 if: ${{ github.event_name == 'workflow_dispatch' && inputs.mode == 'lint-fix' && inputs.allow_prs == true }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8
9 - name: Setup Go (if needed)
10 uses: actions/setup-go@v6
11 with:
12 go-version-file: go.main
13
14 - name: Setup Node (if needed)
15 uses: actions/setup-node@v4
16 with:
17 node-version: '22'
18 cache: npm
19
20 - name: Setup Dart/Flutter (if needed)
21
22 uses: subosito/flutter-action@v2
23 with:
24 channel: stable
25
26 - name: Run autofix formatters
27 shell: bash
28 run: |
29 set -euo pipefail
30 if true; then
31 go fix ./... || true
32 go fmt ./... || true
33 fi
34 if true; then
35 npm ci || true
36 npx prettier . --write || true
37 fi
38 if true; then
39 dart format . || true
40 fi
41
42 - name: Create PR if changes exist
43 env:
44 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
45 shell: bash
46 run: |
47 set -euo pipefail
48 if git diff --quiet; then
49 echo "No changes; exiting."
50 exit 0
51 fi
52
53 git config user.name "github-actions[bot]"
54 git config user.email "41898282+github-actions[bot]@users.noreply.github.com" # Note: you can get this ID using the GitHub API: curl -s https://api.github.com/users/github-actions%5Bbot%5D | jq .id
55
56 PARENT_PR="${{ github.event.pull_request.number || 'none' }}"
57 BRANCH="ci/autofix/${{ github.run_id }}-parent-${PARENT_PR}"
58
59 git checkout -b "$BRANCH"
60 git add -A
61 git commit -m "ci: automated formatting fixes"
62 git push origin "$BRANCH"
63
64 gh pr create \
65 --title "ci: automated formatting fixes" \
66 --body "Automated formatting pass. Parent-PR: ${PARENT_PR}" \
67 --base main \
68 --head "$BRANCH" \
69 --label "ci-autofix"
Cleanup on parent PR close (specific)
1 cleanup-autofix-prs:
2 name: Cleanup autofix PRs on parent close
3 needs: [route]
4 if: ${{ needs.route.outputs.run_cleanup == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - env:
9 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
10 PARENT_PR: ${{ github.event.pull_request.number }}
11 run: |
12 set -euo pipefail
13 gh pr list --state open --search "label:ci-autofix in:title" --json number,headRefName,body | \
14 jq -r '.[] | select(.body | contains("Parent-PR: '"$PARENT_PR"'")) | [.number, .headRefName] | @tsv' | \
15 while IFS=$'\t' read -r pr branch; do
16 gh pr close "$pr" --comment "Closing auto-fix PR because parent PR #$PARENT_PR was closed."
17 git push origin --delete "$branch" || true
18 done
This uses both a label and a guessable branch pattern with parent linkage. Also note the checkout step: if the cleanup job deletes remote branches with git push origin --delete, it needs a repository checkout first.
Repeated gotcha: any git-mutating CI job needs checkout first
If a job runs commands like git push, git push origin --delete, git commit, or branch operations, add checkout as the first step.
1steps:
2 - uses: actions/checkout@v4
3 - run: git push origin --delete "$BRANCH"
Treat this as a hard rule in generated workflows. The same issue repeatedly appears in real repos when cleanup jobs omit checkout.
Step 11: Docker as a release publish step
If repo has Go + Dockerfile or standalone Docker service, build and (optionally) push.
1 docker-build:
2 name: Docker build
3 needs: [route]
4 if: ${{ needs.route.outputs.run_release == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - uses: docker/setup-qemu-action@v3
9 - uses: docker/setup-buildx-action@v3
10 - uses: docker/build-push-action@v6
11 with:
12 context: .
13 file: ${{ hashFiles('Dockerfile.goreleaser') != '' && 'Dockerfile.goreleaser' || 'Dockerfile' }}
14 push: false
15 tags: ghcr.io/${{ github.repository }}:ci-${{ github.run_id }}
16
17 docker-release:
18 name: Docker release
19 needs: [route, docker-build]
20 if: ${{ needs.route.outputs.run_release == 'true' }}
21 runs-on: ubuntu-latest
22 permissions:
23 contents: read
24 packages: write
25 steps:
26 - uses: actions/checkout@v4
27 - uses: docker/setup-qemu-action@v3
28 - uses: docker/setup-buildx-action@v3
29 - uses: docker/login-action@v3
30 with:
31 registry: ghcr.io
32 username: ${{ github.actor }}
33 password: ${{ secrets.GITHUB_TOKEN }}
34 - uses: docker/build-push-action@v6
35 with:
36 context: .
37 push: true
38 tags: |
39 ghcr.io/${{ github.repository }}:${{ github.ref_name }}
40 ghcr.io/${{ github.repository }}:latest
41 platforms: linux/amd64,linux/arm64
Dotfiles/Chezmoi/Docker lessons (high-value niche pattern)
For most app repos, the generic Docker section above is enough. For dotfiles + chezmoi style repos, a few extra checks from a working pipeline are worth copying:
- Shell config validity is a real test target (bash/zsh parse checks after apply).
- Run
chezmoi applyin CI to catch template/rendering regressions early. - Use Docker
build-contextswhen your Dockerfile expects the repo contents as a named context. - Use
docker/metadata-actiontag strategy so manual override tags and semver tags stay consistent. - Package and publish a dotfiles archive (
chezmoi archive) as a first-class release artifact.
Copy/paste pattern:
1 shell-check-and-chezmoi-apply:
2 name: ShellCheck + chezmoi apply
3 needs: [route]
4 if: ${{ needs.route.outputs.run_code_checks == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - name: Install shellcheck and zsh
9 run: sudo apt-get update && sudo apt-get install -y shellcheck zsh
10 - name: ShellCheck scripts
11 run: |
12 shopt -s globstar
13 shellcheck **/*.sh
14 - name: Apply chezmoi source into CI home
15 run: |
16 yes "" | sh -c "$(curl -fsLS get.chezmoi.io)" -- init --no-tty --debug --source=$PWD --apply
17 - name: Verify rendered shell files parse
18 run: |
19 for f in ~/.bashrc ~/.bash_profile ~/.bash_login ~/.bash_logout ~/.profile; do
20 [[ -f "$f" ]] && bash -n "$f"
21 done
22 for f in ~/.zshrc ~/.zprofile ~/.zlogin ~/.zlogout ~/.zshenv; do
23 [[ -f "$f" ]] && zsh -n "$f"
24 done
25
26 docker-release:
27 name: Docker release
28 needs: [route]
29 if: ${{ needs.route.outputs.run_release == 'true' }}
30 runs-on: ubuntu-latest
31 steps:
32 - uses: actions/checkout@v4
33 - uses: docker/setup-qemu-action@v3
34 - uses: docker/setup-buildx-action@v3
35 - uses: docker/login-action@v3
36 with:
37 registry: ghcr.io
38 username: ${{ github.actor }}
39 password: ${{ secrets.GITHUB_TOKEN }}
40 - name: Docker metadata
41 id: meta
42 uses: docker/metadata-action@v5
43 with:
44 images: ghcr.io/${{ github.repository_owner }}/dev-dotfiles-debian
45 tags: |
46 type=ref,event=tag
47 type=semver,pattern={{version}}
48 type=semver,pattern={{major}}.{{minor}}
49 type=raw,value=${{ inputs.release_version_override }},enable=${{ inputs.release_version_override != '' }}
50 type=raw,value=latest,enable={{is_default_branch}}
51 - uses: docker/build-push-action@v6
52 with:
53 context: .
54 build-contexts: dotfiles=.
55 file: containers/dev-dotfiles-debian/Dockerfile
56 push: true
57 tags: ${{ steps.meta.outputs.tags }}
58
59 package-dotfiles:
60 name: Package dotfiles archive
61 needs: [route]
62 if: ${{ needs.route.outputs.run_release == 'true' }}
63 runs-on: ubuntu-latest
64 steps:
65 - uses: actions/checkout@v4
66 - name: Build dotfiles archive
67 run: |
68 yes "" | sh -c "$(curl -fsLS get.chezmoi.io)" -- init --no-tty --debug --source=$PWD --apply
69 ./bin/chezmoi archive --source=$PWD --format zip --output dotfiles.zip
70 - uses: actions/upload-artifact@v4
71 with:
72 name: dotfiles-archive
73 retention-days: 1
74 path: dotfiles.zip
Treat this as an opt-in lane: niche, but very effective when your repo is configuration-driven.
Step 12: GoReleaser lane (binary + packages)
Important reliability guard (from real-world PR fixes): avoid running GoReleaser on both tag-push and release: published for the same version. If both fire, you can get duplicate upload errors (422 already_exists). Keep GoReleaser scoped to:
- tag push events (
push+refs/tags/v*), or - explicit manual release dispatch modes.
If you publish Homebrew formulas, keep the article generic and parameterized, then provide your real tap as an example. For example, a tap can be OWNER/homebrew-tap (your concrete case: arran4/homebrew-tap). For cross-repo updates, set TAP_GITHUB_TOKEN in secrets and wire it to both the workflow env (TAP_GITHUB_TOKEN) and GoReleaser config ({{ .Env.TAP_GITHUB_TOKEN }}), with PR updates enabled and non-draft (draft: false).
Confidence note: the GoReleaser profile used in arran4/go-playerctl (commit 53e2a00) is a strong practical baseline for manual-dispatch releases and should be preferred over purely theoretical snippets when bootstrapping similar Go projects.
Important scope rule: only add binary build/release lanes when the project actually produces binaries. If the repo is a library, config repo, API schema repo, or another non-binary project, keep:
- tagging,
- GitHub release creation,
- release notes generation,
- discussions,
- lint/test/vet/fix/security checks,
- package-manager publication steps that make sense (
npm publish,dart pub publish, etc),
and skip binary-specific lanes like GoReleaser builds, app bundle packaging, Homebrew formulas for non-binaries, or Docker image publishing unless the repository genuinely ships those deliverables.
1 goreleaser:
2 name: GoReleaser
3 # In practice, include all quality gates here (for example: go-test, go-vet, go-lint, format).
4 needs: [route, go-test, prepare-release-tag]
5 if: ${{ (((github.event_name == 'push') && startsWith(github.ref, 'refs/tags/v')) || (github.event_name == 'workflow_dispatch' && startsWith(inputs.mode, 'release-'))) }}
6 runs-on: ubuntu-latest
7 steps:
8 - uses: actions/checkout@v4
9 with:
10 fetch-depth: 0
11 fetch-tags: true
12 - uses: actions/setup-go@v6
13 with:
14 go-version-file: go.main
15 - name: Calculate and Create Tag
16 if: ${{ github.event_name == 'workflow_dispatch' && startsWith(inputs.mode, 'release-') && inputs.mode != 'release-test' && inputs.mode != 'release-rc' && inputs.mode != 'release-alpha' }}
17 run: |
18 git tag ${{ needs.prepare-release-tag.outputs.release_tag }}
19 git push origin ${{ needs.prepare-release-tag.outputs.release_tag }}
20 - name: Run GoReleaser
21 uses: goreleaser/goreleaser-action@v6
22 with:
23 distribution: goreleaser
24 version: '~> v2'
25 args: >-
26 release --clean
27 ${{ (github.event_name == 'workflow_dispatch' && (inputs.mode == 'release-test' || inputs.mode == 'release-rc' || inputs.mode == 'release-alpha')) && '--snapshot' || '' }}
28 env:
29 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
30 TAP_GITHUB_TOKEN: ${{ secrets.TAP_GITHUB_TOKEN }} # inject secrets.TAP_GITHUB_TOKEN
31 GORELEASER_CURRENT_TAG: ${{ needs.prepare-release-tag.outputs.release_tag }}
For release robustness, use an if: guard like this when aggregating many needs:
Important GoReleaser v2 note: avoid --tag in action args (it can fail with “unknown flag: –tag”). Instead set GORELEASER_CURRENT_TAG in env when you need to force the tag value from a prepared job output. For workflow-dispatch releases, also create the local tag on the checked-out commit before running GoReleaser.
Do/Don’t quick check:
1# ❌ Don't (fails on v2):
2# args: release --clean --tag v0.0.1
3
4# ✅ Do:
5# args: release --clean
6# env:
7# GORELEASER_CURRENT_TAG: v0.0.1
1if: ${{ !failure() && !cancelled() && needs.route.outputs.run_release == 'true' }}
Example .goreleaser.yml baseline (copy/paste):
If your repo does not emit a binary, do not cargo-cult this whole file. In that case, keep the manual tag/release flow from Step 15 and any relevant package-publish steps, but omit the GoReleaser binary/archive/container sections entirely.
1project_name: your-project
2
3before:
4 hooks:
5 - go mod tidy
6
7builds:
8 - id: app
9 binary: app
10 main: ./cmd/app
11 env:
12 - CGO_ENABLED=0
13
14archives:
15 - formats: [tar.gz]
16 format_overrides:
17 - goos: windows
18 formats: [zip]
19
20checksum:
21 name_template: checksums.txt
22
23dockers:
24 - image_templates:
25 - ghcr.io/OWNER/REPO:{{ .Tag }}
26 - ghcr.io/OWNER/REPO:latest
27 dockerfile: Dockerfile.goreleaser
28 use: buildx
29 goos: linux
30 goarch: [amd64, arm64]
31
32nfpms:
33 -
34 vendor: Ubels Software Development
35 homepage: https://github.com/arran4/
36 maintainer: Arran Ubels <arran@ubels.com.au>
37 description: NA
38 license: Private
39 formats:
40 - apk
41 - deb
42 - rpm
43 - termux.deb
44 - archlinux
45 release: "1"
46 section: default
47 priority: extra
48 contents:
49 - src: doc/g2.1
50 dst: /usr/share/man/man1/g2.1
51 file_info:
52 mode: 0644
53
54brews:
55 -
56 repository:
57 owner: arran4
58 name: homebrew-tap
59 branch: "{{.ProjectName}}-{{.Version}}"
60 token: "{{ .Env.TAP_GITHUB_TOKEN }}"
61 pull_request:
62 enabled: true
63 draft: false
64 base:
65 owner: arran4
66 name: homebrew-tap
67 branch: main
68 commit_author:
69 name: goreleaserbot
70 email: bot@goreleaser.com
71
72homebrew_casks:
73 -
74 repository:
75 owner: arran4
76 name: homebrew-tap
77 branch: "{{.ProjectName}}-{{.Version}}"
78 token: "{{ .Env.TAP_GITHUB_TOKEN }}"
79 pull_request:
80 enabled: true
81 draft: false
82 base:
83 owner: arran4
84 name: homebrew-tap
85 branch: main
86 commit_author:
87 name: goreleaserbot
88 email: bot@goreleaser.com
89
90scoops:
91 - name: app
92 bucket:
93 owner: OWNER
94 name: scoop-bucket
95
96changelog:
97 sort: asc
98 filters:
99 exclude:
100 - '^docs:'
101 - '^test:'
Important: avoid archive name templates for binaries
Do not set fragile custom archive naming templates for multi-arch binary archives unless you have a very strong reason and a tested collision-proof format.
A proven exception is a template that includes enough uniqueness dimensions (at minimum: project, version, os, arch), like the working go-playerctl pattern.
Why:
- New architectures (for example
windows/arm) can appear over time. - A hand-rolled name template that seemed unique can start colliding.
- Typical failure is
archive ... already existsduring release.
Recommendation:
- Keep GoReleaser archive names on defaults.
- Keep only
format_overridesfor Windows zip/tar differences. - If you ever customize names, include enough dimensions (
project,version,os,arch, and architecture variants) and test against the full matrix before release.
Example of a safer template shape used successfully for manual-dispatch releases:
1archives:
2 - formats: [tar.gz]
3 name_template: >-
4 {{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}
Step 13: Source Debian and Source RPM pipelines (separate lane)
You asked for this explicitly: source package generation should be its own lane and file structure.
Recommended repo layout:
1packaging/
2 debian/
3 control
4 rules
5 changelog
6 source/format
7 rpm/
8 app.spec
9 scripts/
10 build-source-deb.sh
11 build-source-rpm.sh
To create the control file for Debian packaging, you will need to define the package metadata and dependencies. A basic template for packaging/debian/control looks like this:
1Source: app
2Section: utils
3Priority: optional
4Maintainer: Your Name <you@example.com>
5Build-Depends: debhelper (>= 11)
6Standards-Version: 4.1.3
7Homepage: https://example.com
8
9Package: app
10Architecture: any
11Depends: ${shlibs:Depends}, ${misc:Depends}
12Description: App description
13 Detailed description of the app goes here.
Ensure this is configured correctly based on your actual dependencies and package information.
Source Debian lane
1 source-deb:
2 name: Build source .dsc/.orig.tar.*
3 needs: [route]
4 if: ${{ needs.route.outputs.run_release == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - run: sudo apt-get update
9 - run: sudo apt-get install -y devscripts debhelper build-essential fakeroot
10 - name: Build source Debian package
11 run: |
12 chmod +x packaging/scripts/build-source-deb.sh
13 packaging/scripts/build-source-deb.sh
14 - uses: actions/upload-artifact@v4
15 with:
16 name: source-deb
17 retention-days: 1
18 path: |
19 dist/deb-source/*.dsc
20 dist/deb-source/*.debian.tar.*
21 dist/deb-source/*.orig.tar.*
22 dist/deb-source/*.changes
Example packaging/scripts/build-source-deb.sh:
1#!/usr/bin/env bash
2set -euo pipefail
3
4APP_NAME="app"
5VERSION="${GITHUB_REF_NAME#v}"
6WORKDIR="/tmp/${APP_NAME}-${VERSION}"
7OUTDIR="$PWD/dist/deb-source"
8
9rm -rf "$WORKDIR"
10mkdir -p "$WORKDIR" "$OUTDIR"
11
12git archive --format=tar.gz --prefix="${APP_NAME}-${VERSION}/" -o "$OUTDIR/${APP_NAME}_${VERSION}.orig.tar.gz" HEAD
13
14tar -xzf "$OUTDIR/${APP_NAME}_${VERSION}.orig.tar.gz" -C /tmp
15cp -r packaging/debian "/tmp/${APP_NAME}-${VERSION}/debian"
16
17(
18 cd "/tmp/${APP_NAME}-${VERSION}"
19 dch --create -v "${VERSION}-1" --package "$APP_NAME" "Automated source release"
20 dpkg-buildpackage -S -sa
21)
22
23mv /tmp/${APP_NAME}_${VERSION}-1* "$OUTDIR/" || true
Source RPM lane
1 source-rpm:
2 name: Build source .src.rpm
3 needs: [route]
4 if: ${{ needs.route.outputs.run_release == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - run: sudo apt-get update
9 - run: sudo apt-get install -y rpm
10 - name: Build source RPM
11 run: |
12 chmod +x packaging/scripts/build-source-rpm.sh
13 packaging/scripts/build-source-rpm.sh
14 - uses: actions/upload-artifact@v4
15 with:
16 name: source-rpm
17 retention-days: 1
18 path: dist/rpm-source/*.src.rpm
Example packaging/scripts/build-source-rpm.sh:
1#!/usr/bin/env bash
2set -euo pipefail
3
4APP_NAME="app"
5VERSION="${GITHUB_REF_NAME#v}"
6TOPDIR="$PWD/.rpmbuild"
7OUTDIR="$PWD/dist/rpm-source"
8
9mkdir -p "$TOPDIR"/{BUILD,RPMS,SOURCES,SPECS,SRPMS} "$OUTDIR"
10
11git archive --format=tar.gz --prefix="${APP_NAME}-${VERSION}/" -o "$TOPDIR/SOURCES/${APP_NAME}-${VERSION}.tar.gz" HEAD
12cp packaging/rpm/app.spec "$TOPDIR/SPECS/"
13
14rpmbuild \
15 --define "_topdir $TOPDIR" \
16 --define "version $VERSION" \
17 -bs "$TOPDIR/SPECS/app.spec"
18
19cp "$TOPDIR/SRPMS"/*.src.rpm "$OUTDIR/"
This is intentionally independent from fastforge/GoReleaser so source package publishing is never blocked by app-bundle tooling changes.
Step 14: Flatpak and optional app-store packaging lane
For Flutter/Qt desktop apps, keep a manual lane. If Flutter build artifacts were produced earlier, this lane can package those; if not, it can run from source directly.
1 flatpak-build:
2 name: Flatpak package
3 needs: [route]
4 if: ${{ needs.route.outputs.run_release == 'true' }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - run: sudo apt-get update
9 - run: sudo apt-get install -y flatpak flatpak-builder
10 - name: Build Flatpak
11 run: |
12 flatpak-builder --force-clean build-dir packaging/flatpak/app.yaml
13 - uses: actions/upload-artifact@v4
14 with:
15 name: flatpak-bundle
16 retention-days: 1
17 path: build-dir
Step 15: Release fan-in and publish stages
Use multiple deploy stages (package -> publish -> promote).
Manual release creation pattern (gh-release script style)
When you manually create releases, the arran4/dotfiles executable_gh-release.sh flow is a strong pattern, and it closes a common guide gap: generated release notes + discussion creation should be first-class:
- verify default GitHub repo context exists,
- compute version with
git-tag-inc(-print-version-only), - create and push tags with retry,
- create GitHub release with
--generate-notes, - use a default discussion category of
Announcements(safe for default discussion setups), with graceful fallback when permissions/discussions prevent linking, - mark prerelease automatically for
test|alpha|beta|rcincrements. - fetch tags and compare the highest tag version against the source-controlled version before bumping, so release automation never bumps from stale in-repo version text.
You can keep this as a local operator script and wire equivalent logic in CI manual-dispatch mode.
Copy/paste CI step style:
1 manual-gh-release:
2 name: Manual release creation
3 needs: [prepare-release-tag]
4 if: ${{ github.event_name == 'workflow_dispatch' && startsWith(inputs.mode, 'release-') }}
5 runs-on: ubuntu-latest
6 permissions:
7 contents: write
8 discussions: write
9 steps:
10 - uses: actions/checkout@v4
11 with:
12 fetch-depth: 0
13 - name: Sync version source with highest existing tag first
14 run: |
15 set -euo pipefail
16 git fetch --tags --force
17 # For repos with a source-controlled version, bump it to the release version
18 # and commit it before tagging (so the tag includes the bump).
19 # Example for CMake:
20 # RELEASE_VERSION="${{ needs.prepare-release-tag.outputs.release_tag }}"
21 # RELEASE_VERSION="${RELEASE_VERSION#v}"
22 # sed -i -E "s/(project\([^ ]+ VERSION )[^ )]+/\1$RELEASE_VERSION/" CMakeLists.txt
23 # git add CMakeLists.txt
24 # git commit -m "chore: bump release version to $RELEASE_VERSION"
25 - name: Push prepared tag (retry)
26 env:
27 TAG: ${{ needs.prepare-release-tag.outputs.release_tag }}
28 run: |
29 set -euo pipefail
30 git tag -f "$TAG"
31 git push -f origin "$TAG" || { sleep 2; git push -f origin "$TAG"; }
32 - name: Create release with generated notes + discussion
33 env:
34 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
35 TAG: ${{ needs.prepare-release-tag.outputs.release_tag }}
36 run: |
37 set -euo pipefail
38 prerelease=""
39 case "${{ inputs.mode }}" in
40 release-test|release-rc|release-alpha) prerelease="--prerelease" ;;
41 esac
42
43 discussion_arg="--discussion-category Announcements"
44
45 # Permissions/discussions can block discussion linking in some repos.
46 # Fall back to plain release creation if category linking fails.
47 if [[ -n "$prerelease" ]]; then
48 gh release create "$TAG" --generate-notes $prerelease || true
49 else
50 gh release create "$TAG" --generate-notes $discussion_arg || \
51 gh release create "$TAG" --generate-notes
52 fi
Guide requirement: if you include a manual release lane, include both generated notes (--generate-notes) and discussion-category selection fallback logic so the LLM-generated workflow does not omit release discussions in repositories that use them. Use a fixed default discussion category (Announcements) and fall back to plain gh release create --generate-notes when permissions or discussions configuration block category linking. When running in Actions, set permissions.discussions: write (plus contents: write) for this lane.
To avoid duplicate release work, keep artifact publishers scoped by event (for example GoReleaser on tag-push/manual only, not release: published).
Integrate language publishers in the same publish stage:
- Go binaries: GoReleaser publish (GitHub releases + packages)
- Node/TS libraries:
npm publishwithlatest/nextdist-tags - Dart/Flutter libraries:
dart pub publish(or dry-run in non-release modes) - Docker: release-only buildx push to GHCR, but only if the repo actually ships an image
- Non-binary repos: tag + GitHub release + generated notes + discussion flow, without inventing binary artifacts
- Versioned source repos: fetch tags and bump from the maximum of source version and latest tag, not just the checked-in version text
Optional: Prepare next development version PR after release
This pattern from the referenced workflow is useful for repos that keep -SNAPSHOT / development versions in source control.
1 prepare-next-version-pr:
2 name: Prepare next development iteration PR
3 needs: [goreleaser]
4 if: ${{ github.event_name == 'workflow_dispatch' && (startsWith(inputs.mode, 'release-') || inputs.mode == 'release-test') }}
5 runs-on: ubuntu-latest
6 steps:
7 - uses: actions/checkout@v4
8 - name: Bump to next version and open PR
9 env:
10 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
11 run: |
12 set -euo pipefail
13 NEXT_VERSION="${{ needs.prepare-release-tag.outputs.next_version || '' }}"
14 [[ -z "$NEXT_VERSION" ]] && { echo "No next version calculated; skipping."; exit 0; }
15
16 BRANCH="bump-version-$NEXT_VERSION"
17 git config user.name "github-actions[bot]"
18 git config user.email "41898282+github-actions[bot]@users.noreply.github.com" # Note: you can get this ID using the GitHub API: curl -s https://api.github.com/users/github-actions%5Bbot%5D | jq .id
19 git checkout -b "$BRANCH"
20
21 # Replace with repo-specific version bump command(s)
22 # mvn versions:set -DnewVersion="$NEXT_VERSION" -DgenerateBackupPoms=false
23 # sed -i -E "s/(project\([^ ]+ VERSION )[^ )]+/\1$NEXT_VERSION/" CMakeLists.txt
24
25 git add -A
26 git commit -m "Prepare next development iteration $NEXT_VERSION"
27 git push -u origin "$BRANCH"
28 gh pr create --title "Prepare next development iteration $NEXT_VERSION" --body "Automated PR for next iteration." --base main --head "$BRANCH"
Step 16: Full skeleton (compact but wired)
This is the high-level skeleton to start from. Keep this in .github/workflows/ci.yml and split script details into packaging/scripts and config files.
1name: CI/CD
2
3on:
4 push:
5 # We know the repo so the trunk branch should be filtered down / pre selected
6 branches: [main, master]
7 tags: ['v*', 'v*.*.*', 'v*.*.*-rc*', 'v*.*.*-beta*', 'v*.*.*-test*']
8 pull_request:
9 types: [opened, synchronize, reopened, ready_for_review]
10 branches: [main, master]
11 release:
12 types: [published]
13 workflow_dispatch:
14 inputs:
15 mode:
16 type: choice
17 default: lint-fix
18 options: [lint-fix, build, release-major, release-minor, release-patch, release-test, release-rc, release-alpha, monthly-maintenance]
19 release_version_override:
20 type: string
21 default: ''
22 allow_prs:
23 type: boolean
24 default: true
25 schedule:
26 - cron: '0 19 1 * *'
27 - cron: '41 2 * * *'
28
29concurrency:
30 group: ${{ github.workflow }}-${{ github.event_name }}-${{ github.event.pull_request.number || github.ref }}
31 cancel-in-progress: true
32
33permissions:
34 # Remember to only provide permissions where necessary
35 contents: write
36 pull-requests: write
37 checks: write
38 packages: write
39 security-events: write
40
41jobs:
42 route:
43 # ... from section above
44 prepare-release-tag:
45 needs: [route]
46 # ... from section above
47
48 gitleaks:
49 needs: [route]
50 # ...
51
52 java-build-test:
53 needs: [route]
54 # ...
55
56 hugo-build:
57 needs: [route]
58 # ...
59
60 hugo-deploy:
61 needs: [route, hugo-build]
62 # ...
63
64 golangci:
65 needs: [route]
66 # ...
67
68 go-test:
69 needs: [route, golangci]
70 # ...
71
72 go-vet:
73 needs: [route]
74 # ...
75
76 go-fmt-pr:
77 needs: [route]
78 # ...
79
80 node-lint-test:
81 needs: [route]
82 # ...
83
84 dart-analyze-test:
85 needs: [route]
86 # ...
87
88 flutter-analyze-test:
89 needs: [route]
90 # ...
91
92 flutter-build-artifacts:
93 needs: [route, flutter-analyze-test]
94 # ...
95
96 cpp-qt-build-test:
97 needs: [route]
98 # ...
99
100 c-make-build-test:
101 needs: [route]
102 # ...
103
104 docker-build:
105 needs: [route]
106 # ...
107
108 autofix:
109 needs: [route]
110 # ...
111
112 cleanup-autofix-prs:
113 needs: [route]
114 # ...
115
116 goreleaser:
117 needs: [route, go-test, prepare-release-tag]
118 # ...
119
120 source-deb:
121 needs: [route]
122 # ...
123
124 source-rpm:
125 needs: [route]
126 # ...
127
128 docker-release:
129 needs: [route, docker-build]
130 # ...
131
132 prepare-next-version-pr:
133 needs: [goreleaser, prepare-release-tag]
134 # ...
What to decide at install time vs runtime
Install/template time (prefer this):
- expected project stacks,
- release channels,
- package targets,
- which jobs are required.
Runtime (safety):
- file presence detection,
- public/private profile,
- event-mode routing,
- monthly/nightly schedule behavior.
This gives sane defaults while still protecting mixed repos.
Public vs private behavior recommendations
| Area | Public | Private |
|---|---|---|
| OS matrix | Linux default (add macOS/Windows only when required) | Linux default |
| Parallelism | wide job fan-out | narrower job fan-out, parallel inside step |
| Security | broader PR scans | monthly/full-mode deep scans |
| Artifact retention | longer | shorter |
| Validation strictness | maximum | practical baseline + release hardening |
Visibility should be auto-detected (github.event.repository.private) and not manually toggled.
Storage guardrail: artifact expiry policy (important)
To prevent GitHub Actions storage overages, set retention-days on every actions/upload-artifact step.
Required policy for this template:
- set
retention-days: 1on everyactions/upload-artifactstep. - publish/promote jobs should consume artifacts immediately in the same workflow run.
Copy/paste baseline:
1- uses: actions/upload-artifact@v4
2 with:
3 name: ci-temp-output
4 path: dist/**
5 retention-days: 1
Optional monthly cleanup (especially useful for private repos with low storage quota):
1 cleanup-old-artifacts:
2 name: Cleanup old CI artifacts
3 if: ${{ needs.route.outputs.is_monthly == 'true' }}
4 runs-on: ubuntu-latest
5 steps:
6 - name: Delete artifacts older than 1 day
7 env:
8 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
9 run: |
10 set -euo pipefail
11 cutoff=$(date -u -d '1 day ago' +%s)
12 gh api repos/${{ github.repository }}/actions/artifacts --paginate \
13 --jq '.artifacts[] | [.id, .created_at] | @tsv' | \
14 while IFS=$' ' read -r id created; do
15 created_epoch=$(date -u -d "$created" +%s)
16 if (( created_epoch < cutoff )); then
17 gh api -X DELETE repos/${{ github.repository }}/actions/artifacts/$id || true
18 fi
19 done
Final checklist before rollout
- Add config files (
.golangci.yml,.goreleaser.yml,analysis_options.yaml,.gitleaks.toml,.clang-format). - Add packaging scripts under
packaging/scripts/. - Add
packaging/debianandpackaging/rpmmetadata. - Dry-run with
workflow_dispatch mode=buildormode=lint-fix. - Validate
lint-fixcreates/labels branches correctly. - Validate
pull_request.closedcleanup against test PRs. - Validate monthly schedule and release lanes.
- Validate that every
git-mutating job starts withactions/checkout@v4.
README distribution/install checklist (do not skip)
When you add release lanes, don’t forget to update README.md so users know how to install from each release target. They should be at “next” in some cases and “current” in others such as install instructions. This may be done using pull requests if toggled. Match the README to what the repo actually ships; if there is no binary, do not add fake binary install instructions just because the template has them. At minimum, list:
- GitHub Releases (binary/tarball download path),
- Homebrew tap install command,
- Docker image pull/run command,
- Go install command for Go CLIs,
- native package methods (
deb,rpm,apk,archlinux) where available.
Copy/paste template:
1## Install
2
3### GitHub Releases
4Download binaries from: https://github.com/OWNER/REPO/releases
5
6### Homebrew
7brew tap OWNER/homebrew-tap
8brew install app
9
10### Docker
11docker pull ghcr.io/OWNER/REPO:latest
12docker run --rm ghcr.io/OWNER/REPO:latest --help
13
14### Go install
15go install github.com/OWNER/REPO/cmd/app@latest
16
17### Native packages
18- Debian/Ubuntu (`.deb`): see Releases assets
19- RPM (`.rpm`): see Releases assets
20- Alpine (`.apk`): see Releases assets
21- Arch (`.pkg.tar.zst` or repo): see Releases assets
This keeps release automation and user-facing install documentation aligned.
Closing
If your goal is “one CI file that does everything”, make it explicit, sectioned, and policy-driven.
The winning pattern is:
- route events,
- detect capabilities,
- branch by profile,
- run language lanes in parallel,
- split release lanes by output type,
- and automate cleanup lifecycle.
That gives you the giant file you wanted, with practical behavior for real repos rather than demo YAML.
Troubleshooting: GoReleaser fatal: tag already exists
If you use GoReleaser inside your GitHub Action workflow to automatically build and release binaries, you might occasionally encounter an error that halts your pipeline:
1Run git tag v0.0.2
2
3fatal: tag 'v0.0.2' already exists
4
5Error: Process completed with exit code 128.
Git correctly refuses to create a tag that has already been created. This typically happens when:
- Triggering manually without incrementing the version: If you have a
workflow_dispatchtrigger that takes a version string, running it twice with the same version will fail the second time. - Failed previous releases: If your CI workflow previously ran and successfully created the tag but failed in a later step (e.g., during building or uploading assets), the tag will still exist. Re-running the pipeline hits the same tagging step and fails.
- Duplicate automated tagging: Your script may unconditionally attempt to tag the commit without first checking if the remote branch already has that tag.
Option 1: Delete the conflicting tag and retry (For failed releases)
If you are explicitly trying to retry or overwrite that exact same release version (e.g., v0.0.2) due to a failed pipeline, you must delete the tag both locally and remotely:
1# Delete the tag locally
2git tag -d v0.0.2
3
4# Delete the tag on the remote repository
5git push origin :refs/tags/v0.0.2
Once removed from the remote, you can safely trigger your workflow again.
Option 2: Increment the version (For new releases)
If the previous release was successful and you are actually trying to push new changes, increment your version number according to Semantic Versioning (e.g., to v0.0.3) and trigger the workflow with the new tag:
1git tag v0.0.3
2git push origin v0.0.3