diff --git a/.forgejo/workflows/release.yml b/.forgejo/workflows/release.yml deleted file mode 100644 index df93c59..0000000 --- a/.forgejo/workflows/release.yml +++ /dev/null @@ -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=). - 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 diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md index 43cbb3d..1567ddd 100644 --- a/docs/CHANGELOG.md +++ b/docs/CHANGELOG.md @@ -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 diff --git a/docs/DEVELOPMENT.md b/docs/DEVELOPMENT.md index 251e3c3..a602b2f 100644 --- a/docs/DEVELOPMENT.md +++ b/docs/DEVELOPMENT.md @@ -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. diff --git a/scripts/ci-build-release.sh b/scripts/ci-build-release.sh index 7ce0dfa..c780d03 100755 --- a/scripts/ci-build-release.sh +++ b/scripts/ci-build-release.sh @@ -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