Files
kolmekivi/.github/workflows/ci.yaml
T
mikkeli 9675905401 ci: let a workflow change validate itself
Adds .github/workflows/** to both path filters. A broken step, a moved
script path or a wrong runner label now fails on the commit that caused
it, instead of surfacing later against an unrelated source change and
looking like that change's fault.

This session produced exactly that bug: after the branding tools moved
under tools/, the workflow still ran `sh check-branding.sh` at the old
path, and it was caught by reading the file rather than by CI.

The limit is worth stating: this validates the job body, not the trigger
block. Break `on:` and the symptom is silence, which is indistinguishable
from success.

Workflow edits are rare enough that the extra builds cost nothing, and CI
config is the definition of how the project is built and verified — it
belongs on the source side of "source code edits only", not with the docs.

kolmekivi additionally gains the pull_request path filter the other two
already had.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
2026-09-04 19:33:12 +09:00

78 lines
2.6 KiB
YAML

name: CI
on:
push:
branches: [ master ]
paths:
- 'src/**'
- 'xtask/**'
- 'Cargo.toml'
- 'Cargo.lock'
- 'bundler.toml'
- 'tools/**'
# This workflow validates itself: a broken step, a moved script path or a
# wrong runner label then fails loudly on the commit that caused it, rather
# than surfacing later against an unrelated source change. Note the limit -
# it checks the job body, not the trigger block above. Break `on:` and the
# symptom is silence, which looks like success.
- '.github/workflows/**'
# Mirrors the push filter. Without it a PR touching only the README would run a
# full build - the branch filter alone constrains where, not what.
pull_request:
branches: [ master ]
paths:
- 'src/**'
- 'xtask/**'
- 'Cargo.toml'
- 'Cargo.lock'
- 'bundler.toml'
- 'tools/**'
- '.github/workflows/**'
workflow_dispatch:
# Target the self-hosted Rust/audio runner registered to the `musiikki` org.
#
# The runner is host-mode, so the rustup toolchain installed for the
# `gitea-runner` user is used directly — nothing installs per run, and the cargo
# registry cache stays warm between jobs.
#
# NOTE: `rust-audio` is an ORG-SCOPED label. A plugin cloned from this template
# into a different org will not see that runner, and its jobs will queue
# indefinitely rather than fail. Either register a runner advertising this label
# for that org, or change `runs-on` below.
jobs:
build:
name: Build
runs-on: rust-audio
steps:
- uses: actions/checkout@v4
- name: Toolchain
run: |
cargo --version
rustc --version
echo "CARGO_HOME=${CARGO_HOME:?not set on this runner}"
# Cheap and needs no toolchain, so it runs first: a rename that only
# landed in half the files is worth catching before spending a build on it.
- name: Branding consistency
run: sh tools/check-branding.sh
# The default build is CLAP-only; the vst3 feature is opt-in, so both
# configurations have to be built to know the cfg gates are still correct.
- name: Build (default, CLAP only)
run: cargo build --release
- name: Build (--features vst3)
run: cargo build --release --features vst3
- name: Test
run: cargo test --release --features vst3
# Proves the xtask bundler still works, which a plain `cargo build` does
# not exercise — the bundle step is where bundler.toml and the crate name
# have to agree.
- name: Bundle
run: cargo xtask bundle kolmekivi --release --features vst3