ci(release): automate plugin releases via workflow_dispatch
CI / editor tests (push) Successful in 41s

Adds a dispatch-triggered Release workflow for the plugin: enter a version
in the Actions UI and it stamps g:nuwiki_version in plugin/nuwiki.vim,
sanity-checks the plugin still sources (+ exposes the stamped version),
commits chore(release): X.Y.Z, pushes the vX.Y.Z tag, and publishes a Gitea
release with notes. No binary build — the plugin ships none; nuwiki-ls is
fetched from nuwiki-rs at install time. Dispatch-only so the self-created
tag doesn't double-fire.

Updates ONBOARDING (tree, CI/CD, "Releasing the plugin") to match.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-24 16:26:28 +00:00
parent 3859d3b0e7
commit 101cb1cea9
2 changed files with 167 additions and 14 deletions
+16 -14
View File
@@ -59,11 +59,13 @@ nuwiki/
└── .gitea/
└── workflows/
── ci.yaml # Editor (Vim/Neovim) harnesses on every push/PR
── ci.yaml # Editor (Vim/Neovim) harnesses on every push/PR
└── release.yaml # Dispatch → stamp version, tag, Gitea release (no build)
```
(The Rust server's build/release workflow lives in the separate
[nuwiki-rs](https://code.gfran.co/gffranco/nuwiki-rs) repository.)
(The Rust server's *binary* build/cross-compile workflow lives in the separate
[nuwiki-rs](https://code.gfran.co/gffranco/nuwiki-rs) repository; this repo's
release just tags the plugin.)
## Server Component
@@ -200,23 +202,23 @@ To modify the LSP server itself, clone the [nuwiki-rs](https://code.gfran.co/gff
## CI/CD
This repo (editor client) uses Gitea Actions:
- CI (`.gitea/workflows/ci.yaml`): Runs editor tests on every push/PR.
- CI (`.gitea/workflows/ci.yaml`): Runs the editor harnesses on every push/PR.
- Release (`.gitea/workflows/release.yaml`): `workflow_dispatch` with a `version` input — stamps `g:nuwiki_version`, tags `vX.Y.Z`, and publishes a Gitea release. No binary build (the plugin ships none).
The Rust LSP server lives in [nuwiki-rs](https://code.gfran.co/gffranco/nuwiki-rs) which handles:
- Release (`.gitea/workflows/release.yaml`): Triggers on `v*` tag — cross-compiles for Linux targets and creates a Gitea release with downloadable binaries.
The Rust LSP server lives in [nuwiki-rs](https://code.gfran.co/gffranco/nuwiki-rs) which has its own release workflow — it cross-compiles `nuwiki-ls` for Linux targets and publishes the downloadable binaries the plugin fetches.
### Releasing the plugin
This repo has no release workflow — the plugin is distributed by plugin
managers cloning the git repo, so a "release" is just a git tag. There is no
automated version stamping (the old `scripts/set-version.sh` moved to
nuwiki-rs with the Rust crates), so cut a plugin release by hand:
1. Bump `g:nuwiki_version` in `plugin/nuwiki.vim`.
2. Commit, then `git tag vX.Y.Z && git push --tags`.
Releases are cut from the Actions UI — **Release** workflow
(`.gitea/workflows/release.yaml`) → **Run workflow** → enter the version
(e.g. `0.5.1`). It stamps `g:nuwiki_version` in `plugin/nuwiki.vim`,
sanity-checks that the plugin still sources, commits `chore(release): X.Y.Z`,
pushes the `vX.Y.Z` tag, and publishes a Gitea release entry. The plugin ships
no binary, so the release carries no assets by design.
The plugin and the `nuwiki-ls` server version independently; the binary is
fetched from nuwiki-rs's `latest` release at install time.
fetched from nuwiki-rs's `latest` release at install time. To do it by hand
instead: bump `g:nuwiki_version`, commit, then `git tag vX.Y.Z && git push --tags`.
## License