petrbalvin/nuntius
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

chore: migrate CI to Gitea actions and update module path

Browse Source
This commit is contained in:
petrbalvin
2026-07-26 20:29:01 +02:00
parent 1b700f7975
commit db3860328b
13 changed files with 60 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+11 -11
View File
@@ -24,7 +24,7 @@ See [Cutting a release](#cutting-a-release) for the full procedure.
### Quick Start
```bash
git clone https://codeberg.org/petrbalvin/nuntius.git
git clone https://sourcedock.dev/petrbalvin/nuntius.git
cd nuntius
just install # go mod tidy + go mod download (no third-party modules — no-op for this project)
just build # → ./bin/nuntius (with -ldflags="-s -w")
@@ -203,11 +203,11 @@ graph TD
## CI
This project uses **Forgejo Actions** for continuous integration. The two workflow files live under `.forgejo/workflows/` and are the source of truth for what runs on every push and on every tagged release.
This project uses **Gitea Actions** for continuous integration. The two workflow files live under `.gitea/workflows/` and are the source of truth for what runs on every push and on every tagged release.
### Test workflow — `.forgejo/workflows/test.yml`
### Test workflow — `.gitea/workflows/test.yml`
Triggered on every push to `development` and on every pull request targeting `development`. `main` is excluded on purpose — it only ever receives release tags, and the release workflow builds the binaries itself. Three jobs run in sequence, all on the `codeberg-small` runner:
Triggered on every push to `development` and on every pull request targeting `development`. `main` is excluded on purpose — it only ever receives release tags, and the release workflow builds the binaries itself. Three jobs run in sequence, all on the `fedora` runner:
| Job | What it does | Why it exists |
|---|---|---|
@@ -225,23 +225,23 @@ just build
./bin/nuntius --version # sanity-check the new flag
```
### Release workflow — `.forgejo/workflows/release.yml`
### Release workflow — `.gitea/workflows/release.yml`
Triggered by pushing a tag that matches `v*.*.*` (e.g. `v1.0.0`, `v1.2.3`) onto `main`. The merge from `development` into `main` is the maintainer's responsibility and happens before the tag is pushed — this workflow does not merge anything. Two jobs:
1. **`build`** — Runs on a `codeberg-small` runner in a 4-way matrix: `linux/amd64`, `linux/arm64`, `freebsd/amd64`, `freebsd/arm64`. The default `actions/checkout@v4` checks out the tagged commit (the trigger was a tag push), which is exactly the commit on `main` we want to ship. The version is baked in via `-ldflags`:
1. **`build`** — Runs on a `fedora` runner in a 4-way matrix: `linux/amd64`, `linux/arm64`, `freebsd/amd64`, `freebsd/arm64`. The default `actions/checkout@v4` checks out the tagged commit (the trigger was a tag push), which is exactly the commit on `main` we want to ship. The version is baked in via `-ldflags`:
```bash
-X codeberg.org/petrbalvin/nuntius/internal/version.Version=${VERSION#v}
-X sourcedock.dev/petrbalvin/nuntius/internal/version.Version=${VERSION#v}
```
The resulting binary is uploaded as a workflow artifact and smoke-tested with `--version` on the build host.
2. **`release`** — Runs on a `codeberg-tiny` runner (no Go toolchain needed). Downloads all artifacts, extracts the matching section from `CHANGELOG.md` for the tagged version, creates a release via the Forgejo REST API, and uploads each binary as a release asset. The release is **non-draft, non-prerelease**; if the CHANGELOG section is missing, the job fails fast so a release cannot ship without notes.
2. **`release`** — Runs on a `fedora` runner (no Go toolchain needed). Downloads all artifacts, extracts the matching section from `CHANGELOG.md` for the tagged version, creates a release via the Gitea REST API, and uploads each binary as a release asset. The release is **non-draft, non-prerelease**; if the CHANGELOG section is missing, the job fails fast so a release cannot ship without notes.
### Cutting a release
1. Bump `Version` in `internal/version/version.go`.
2. Add a new `## [X.Y.Z] — YYYY-MM-DD` section at the top of `CHANGELOG.md`.
3. Make sure CI is green on `development` (pushes and PRs against `development` are what the test workflow runs on).
4. Merge `development` into `main` (e.g. open a PR on Forgejo, or `git checkout main && git merge --no-ff development && git push origin main`). This is the **only** step where `main` is updated outside of a tag push.
4. Merge `development` into `main` (e.g. open a PR on Gitea, or `git checkout main && git merge --no-ff development && git push origin main`). This is the **only** step where `main` is updated outside of a tag push.
5. Tag the `main` tip and push the tag:
```bash
git tag -a vX.Y.Z -m "nuntius vX.Y.Z"
@@ -250,7 +250,7 @@ Triggered by pushing a tag that matches `v*.*.*` (e.g. `v1.0.0`, `v1.2.3`) onto
```
6. The release workflow builds the four platform binaries and creates the release with the CHANGELOG section as the body. No CI step performs the merge — that already happened in step 4.
If the release job fails, the tag can be deleted and re-pushed; the workflow re-runs on the new tag push. Do not re-tag an already-released commit — the Forgejo API rejects duplicate release tag names.
If the release job fails, the tag can be deleted and re-pushed; the workflow re-runs on the new tag push. Do not re-tag an already-released commit — the Gitea API rejects duplicate release tag names.
## Adding a New Form Type
@@ -264,7 +264,7 @@ The four current types (`contact`, `feedback`, `newsletter`, `generic`) live in
## Report a Bug
Open an issue at <https://codeberg.org/petrbalvin/nuntius/issues> with:
Open an issue at <https://sourcedock.dev/petrbalvin/nuntius/issues> with:
- nuntius version (`./bin/nuntius --version`).
- Operating system and architecture.