mix/gosentry
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: drop Codeberg release workflow and document GitHub-only CI

Browse Source 
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
mixemeandCursor committed 2026-10-21 23:51:54 +03:00
1 parent 8535b873a6
commit 33d0d179e0
4 files changed
+23 -131
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.forgejo/workflows/release.yml
-108
View File
@@ -1,108 +0,0 @@
name: Release
# Forgejo Actions workflow for Codeberg. It mirrors .github/workflows/release.yml
# and reuses the same scripts/ci-build-release.sh, so the actual build/package
# commands live in exactly one place. Codeberg has no Windows runners, but the
# Windows binary is cross-compiled with MinGW-w64 from the Linux job, so a single
# golang:1.22-bookworm container produces all three artifacts.
#
# Publishing needs a token that can write releases. Add a repository secret named
# RELEASE_TOKEN (a Codeberg access token with the "write:repository" scope) under
# Settings -> Actions -> Secrets. Without it the build still runs; only the
# upload step is skipped.
on:
release:
types: [published]
workflow_dispatch:
jobs:
release:
# Codeberg's hosted runners are tagged codeberg-tiny/small/medium (+ -lazy);
# there is no "docker" tag. The non-lazy runners cap at 2/5/10 min, which the
# three CGO cross-compiles blow past, so use the medium *-lazy* runner, which
# relaxes the wall-clock limit (it aims to finish within 24h).
runs-on: codeberg-medium-lazy
container:
image: golang:1.22-bookworm
steps:
- name: Provide Node.js for JS actions
# golang:1.22-bookworm ships no Node, and Codeberg's runner does not
# inject one, so JS actions (checkout, forgejo-release) fail with
# "node: not found". A run step executes through the container shell and
# needs no Node itself, so it can install Node before those actions run.
# (If a "node version" error ever appears, swap Debian's nodejs 18 for a
# NodeSource node 20 install.)
run: |
apt-get update
apt-get install -y --no-install-recommends nodejs
command -v node || ln -s "$(command -v nodejs)" /usr/local/bin/node
- name: Checkout
uses: https://code.forgejo.org/actions/checkout@v4
- name: Install cross toolchain
# Same package list as the repo Dockerfile / GitHub workflow: native gcc
# plus X11/GL headers, the aarch64 cross compiler with arm64 runtime
# libs, MinGW-w64 for the Windows GUI binary, and zip for packaging.
run: |
dpkg --add-architecture arm64
apt-get update
apt-get install -y --no-install-recommends \
ca-certificates \
gcc \
libc6-dev \
gcc-aarch64-linux-gnu \
libc6-dev-arm64-cross \
linux-libc-dev-arm64-cross \
gcc-mingw-w64-x86-64 \
binutils-mingw-w64-x86-64 \
pkg-config \
libgl1-mesa-dev \
xorg-dev \
libgl1-mesa-dev:arm64 \
libx11-dev:arm64 \
libxcursor-dev:arm64 \
libxrandr-dev:arm64 \
libxinerama-dev:arm64 \
libxi-dev:arm64 \
libxxf86vm-dev:arm64 \
zip
rm -rf /var/lib/apt/lists/*
- name: Derive version
# On a release, strip the leading "v" so artifact names and the injected
# app version match the release tag (the release event still sets
# GITHUB_REF_TYPE=tag / GITHUB_REF_NAME=<tag>).
id: version
run: |
if [ "${GITHUB_REF_TYPE:-}" = "tag" ]; then
echo "value=${GITHUB_REF_NAME#v}" >> "$GITHUB_OUTPUT"
fi
- name: Build and package
env:
VERSION: ${{ steps.version.outputs.value }}
run: |
chmod +x scripts/ci-build-release.sh
scripts/ci-build-release.sh
- name: Collect release files
# forgejo-release uploads every file in a single directory, so gather the
# archives into one flat folder.
run: |
mkdir -p dist/release
cp dist/linux/*.tar.gz dist/windows/*.zip dist/release/
- name: Attach assets to release
# Only runs for the release event; the release already exists, so this
# uploads the built archives to it. Skipped on workflow_dispatch.
if: ${{ github.event_name == 'release' }}
uses: https://code.forgejo.org/actions/forgejo-release@v2
with:
direction: upload
url: https://codeberg.org
repo: ${{ github.repository }}
tag: ${{ github.event.release.tag_name }}
release-dir: dist/release
token: ${{ secrets.RELEASE_TOKEN }}
override: true
docs/CHANGELOG.md
+7
View File
@@ -7,6 +7,13 @@ All notable GoSentry changes are recorded in this file.
**The remaining over-the-guideline source files are split; the roadmap is
restructured around what actually blocks each item.**
**Internal:**
- **Codeberg / Forgejo Actions** — release publishing no longer targets
Codeberg. Removed `.forgejo/workflows/release.yml` and updated
`DEVELOPMENT.md` and `ci-build-release.sh` so CI is documented as GitHub
Actions only; Gitea remains `origin` with a pruning push mirror to GitHub.
**Documentation:**
- **`ROADMAP.md`** — reorganized into Features, Platform, Fyne/UI, and
docs/DEVELOPMENT.md
+12 -19
View File
@@ -35,7 +35,7 @@ executable per platform.
| Persistence | Plain JSON files (`gosentry.json`, `jobs.json`) |
| Build | `go build` driven by the scripts in `scripts/` |
| Reproducible builds | Docker (`golang:1.22-bookworm` based [Dockerfile](../Dockerfile)) |
| CI | GitHub Actions and Forgejo Actions (Codeberg) |
| CI | GitHub Actions (release builds on tagged GitHub Releases) |
CGO is mandatory. The Fyne desktop backend links against native OpenGL and
window-system libraries, so a C compiler must be present for every build,
@@ -255,12 +255,11 @@ The version stamped into the file names and into the binary comes from
## 6. CI
Tagged releases are built automatically on both GitHub and Codeberg:
Tagged releases are built automatically on GitHub when a release is published:
- `.github/workflows/release.yml` — GitHub Actions.
- `.forgejo/workflows/release.yml` — Forgejo Actions (Codeberg).
Both run inside `golang:1.22-bookworm` (the same base image as the
The job runs inside `golang:1.22-bookworm` (the same base image as the
[Dockerfile](../Dockerfile)), install the cross toolchain, and call
`scripts/ci-build-release.sh`, which builds and packages all three artifacts:
@@ -290,15 +289,16 @@ Before tagging:
4. Run `scripts/test.bat` (or `go vet ./... && go test -race ./...`) and push
`main`, so the tag lands on a commit the forge actually has.
Then create and publish a release with a matching `v` tag on the forge (GitHub
Releases / Codeberg releases). `origin` is the Gitea repository, and GitHub is a
push mirror of it, so the tag is pushed to Gitea and reaches GitHub through the
mirror — never created on GitHub directly (see
Then create and publish a release with a matching `v` tag on GitHub. `origin` is
the Gitea repository (`gitea.mixdep.ru/mix/gosentry`), and GitHub
[`mixeme/gosentry`](https://github.com/mixeme/gosentry) is a pruning push mirror
of it, so the tag is pushed to Gitea and reaches GitHub through the mirror —
never created on GitHub directly (see
[Releasing through the GitHub push mirror](#releasing-through-the-github-push-mirror)):
```bash
git tag v0.11.5
git push origin v0.11.5 # Gitea; and to the Codeberg remote
git push origin v0.11.5 # Gitea
# wait for the mirror, then confirm GitHub actually has the tag
git ls-remote --tags https://github.com/mixeme/gosentry.git v0.11.5
@@ -310,14 +310,8 @@ Publishing the release triggers the workflow: it strips the leading `v` from
the tag and injects it as the version (so the tag must match `version.go`),
builds the archives, and attaches them to that release. `workflow_dispatch`
also allows a manual, upload-free build to smoke-test the pipeline.
Codeberg publishing needs a repository secret named `RELEASE_TOKEN` (a Codeberg
access token with the `write:repository` scope) under
**Settings → Actions → Secrets**. Without it the build and packaging steps still
succeed, but the upload step fails on authentication and takes the job down with
it, leaving a published release with no attached assets. GitHub needs no such
setup: `softprops/action-gh-release` falls back to the built-in `GITHUB_TOKEN`,
and the workflow already grants it `contents: write`.
`softprops/action-gh-release` uses the built-in `GITHUB_TOKEN`; the workflow
already grants it `contents: write`.
### Releasing through the GitHub push mirror
@@ -348,5 +342,4 @@ them, so once the release sits on a mirrored tag, later synchronisations leave
it alone. Two consequences follow. Moving a published tag in Gitea force-pushes
it on GitHub and leaves the release pointing at a different commit, and deleting
a published tag in Gitea destroys the GitHub release along with its uploaded
archives — neither is recoverable from the mirror side. Codeberg is unaffected:
its releases live in the same forge as its tags.
archives — neither is recoverable from the mirror side.
scripts/ci-build-release.sh
+4 -4
View File
@@ -4,10 +4,10 @@ set -euo pipefail
# Build and package every release artifact on a Linux host that already has the
# cross toolchain installed (native gcc + X11/OpenGL headers, the aarch64 cross
# compiler, and the MinGW-w64 toolchain for the Windows GUI binary). This is the
# non-Docker counterpart to scripts/build-release-linux.sh: the CI workflows in
# .github/ and .forgejo/ install those packages directly on the runner and then
# call this script, so the exact build/package commands live in one place and do
# not drift between the two forges.
# non-Docker counterpart to scripts/build-release-linux.sh: the GitHub Actions
# release workflow installs those packages directly on the runner and then calls
# this script, so the exact build/package commands live in one place and do not
# drift from local release builds.
#
# The build flags mirror the other scripts intentionally: -trimpath strips local
# paths, -s -w drops symbol/debug tables to shrink the binaries, -H=windowsgui