ci: any Linux runner; build per tag or dispatch, drop cron and matrix
build / build (push) Has been cancelled

runs-on is now ubuntu-latest (any Linux runner with Docker; toolchain comes from the golang container). The workflow builds one version per run, triggered by a v* tag push or manual workflow_dispatch with a tag input - no scheduled builds. Removes the static matrix (and ci/matrix.sh) and hardens clone-source.sh tag detection to use GITHUB_REF. Docs/README updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
William GillandClaude Opus 4.8 committed 2026-06-15 13:29:20 -05:00
1 parent 6b35d863c9
commit 8814a6e239
5 files changed
+73 -105

No files matched your search

+28 -29
View File
@@ -5,14 +5,17 @@ release into a de-branded build, and how to keep it tracking new
upstream versions. This mirrors the scoutfs-build / scoutfs-notify
model, collapsed into one repo because the patch set is small.
CI builds **one version per run** — triggered by a tag push or a manual
dispatch, never on a schedule.
## The flow
Each build is four steps, run per upstream tag:
Each build is four steps, run for a single upstream tag:
1. **`ci/clone-source.sh`** — shallow-clones upstream versitygw at a
tag into `src/`. Tag selection priority:
1. `VGW_TAG` (set by the CI matrix or a manual run),
2. the pushed tag (`GITHUB_REF_NAME` when `GITHUB_REF_TYPE=tag`),
1. `VGW_TAG` (the dispatch input, or a manual run),
2. the pushed tag (`GITHUB_REF` = `refs/tags/...`),
3. the latest remote `vX.Y.Z` tag.
The checkout forces `core.autocrlf=false` so the tree is byte-for-
byte upstream (LF) and the LF patches apply on any host.
@@ -33,9 +36,9 @@ Each build is four steps, run per upstream tag:
4. **`ci/publish-release.sh`** — creates (or reuses) a Gitea release for
the tag in this repo and uploads `src/dist/*` as assets. Idempotent:
re-running replaces existing assets, so daily rebuilds are safe.
re-running for the same tag replaces existing assets.
## The source of truth: `ci/support-matrix.yaml`
## Patch registry: `ci/support-matrix.yaml`
```yaml
versitygw:
@@ -43,19 +46,14 @@ versitygw:
patches: v1.5.0
```
- `tag` — upstream git tag to build.
- `tag` — upstream git tag.
- `patches` — directory under `patches/` to apply (defaults to `tag`).
Point several tags at one directory if the same series applies to a
range of upstream releases.
The highest-version entry is "latest". `bash ci/matrix.sh` prints the
matrix this file implies.
> **Act Runner caveat.** Gitea's Act Runner does not support dynamic
> matrices (`matrix: ${{ fromJSON(...) }}`). The workflow therefore
> carries a **static** `matrix:` that you must keep in sync with this
> file by hand — same compromise scoutfs-build makes. `ci/matrix.sh`
> exists to diff/preview, not to feed CI.
`apply-patches.sh` consults this to find the patch directory for the tag
being built; with the default `patches/<tag>/` naming it doubles as a
human-readable record of which versions are maintained.
## Adding a new upstream version
@@ -86,11 +84,11 @@ When upstream releases `vX.Y.Z`:
patches: v1.5.0
```
3. **Mirror it** into the static `matrix.include` in
`.gitea/workflows/build.yml`.
3. **Commit and push** `ci/support-matrix.yaml` + `patches/vX.Y.Z/`.
4. Commit and push. The next CI run builds and publishes the new
version alongside the existing ones.
4. **Build it** — either push a `vX.Y.Z` tag to this repo, or run the
**build** workflow manually and enter `vX.Y.Z`. CI builds that one
version and publishes it.
### Sanity-check a series before committing
@@ -100,25 +98,26 @@ VGW_REPO_URL="/path/to/local/versitygw" VGW_TAG=vX.Y.Z bash ci/run.sh
A clean `git am` plus a populated `src/dist/` means the series is good.
## Aging out a version
## Removing a version
Remove its entry from `ci/support-matrix.yaml` and the workflow matrix.
CI stops building it; releases already published in this repo stay until
you delete them manually. You can keep the `patches/<tag>/` directory
for history or remove it.
Delete its `patches/<tag>/` directory and its `ci/support-matrix.yaml`
entry. Releases already published in this repo stay until you delete
them by hand.
## CI configuration
- **Runner**: `runs-on: s3-gateway-ci`. Add that label to your existing
scoutfs-ci Act Runner, or change the label.
- **Triggers**: a `v*` tag push (builds that tag) or manual dispatch
with a tag input (one-shot). No cron.
- **Runner**: any Linux runner — `runs-on: ubuntu-latest`. The Go
toolchain comes from the `golang:latest` container, so the runner
only needs Docker; nothing version-specific to install.
- **Container**: `golang:latest` — pure-Go build, GoReleaser's bundled
nfpm makes deb/rpm without rpmbuild/dpkg.
- **Secret `TOKEN_GITEA`**: Gitea PAT with **write:repository**. Used
both to clone this repo (the workflow does a manual token-rewritten
clone, mirroring scoutfs-build, since a stock container has no Node
for `actions/checkout`) and to publish releases.
- **Variable `VGW_REPO_URL`** (optional): override the upstream URL,
e.g. to build from a mirror.
clone, since a stock container has no Node for `actions/checkout`) and
to publish releases.
- **Variable `VGW_REPO_URL`** (optional): override the upstream URL.
## Release tagging