8c24b83ea3
Three changes that only make sense together. **tools/**. check-branding.sh, brand-plugin.sh and branding.conf were accumulating in the repo root, and a deploy.sh/bat/ps1 set would land there too. They now live in tools/ and resolve the repo root explicitly rather than assuming their own directory is it, so they behave the same however they are invoked. **One name drives the rest.** branding.conf now derives the package name, the Rust types and the display name from PLUGIN_NAME, each overridable. Derivation-by-default removes a class of drift; the override matters because the derivation is sometimes invalid — "206 Prototype" derives to "206_prototype", which cargo rejects outright — and because PLUGIN_NAME is cosmetic while the package name is structural. A display tweak should not silently rename the crate, its bundle lookup, the CI command and the lockfile. This template overrides three of them, which a real plugin normally will not: its names are the template's own rather than derived from a product name. An overridden PKG that no longer matches the derivation is reported at info level, never failed. The override is usually deliberate; a display rename that forgot the package looks identical from here, and is not. **The site table is data.** branding-sites.tsv lists every place a name must appear and in what form; check-branding.sh iterates it instead of carrying 29 check calls in shell. The scripts are now identical across every plugin built from this template, with only the table and conf differing — which matters because the template and codename-206 had already diverged by two checks, so every sync was a shell merge. brand-plugin.sh regenerates the rows it owns and preserves the rest, so a hand-added row for a file this template does not ship survives a rename. Custom rows are value-substituted like any other tracked file, so they track the rename rather than going stale — the first cut excluded the whole table from substitution and got that wrong. brand-plugin.sh also gained an interactive mode: run it with no arguments and it prompts for each value with the current one as the default, so Enter keeps it and a run that answers nothing changes nothing. It only engages when there is a terminal to ask at, so CI gets the usage message and exit 2 rather than a hang. Verified by applying a full rename to a sandboxed copy: 8 files rewritten, 29 owned rows regenerated, 1 custom row preserved and substituted, checker green at 48/0/7, and the result compiles as bari_206. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
62 lines
1.9 KiB
YAML
62 lines
1.9 KiB
YAML
name: CI
|
|
|
|
on:
|
|
push:
|
|
branches: [ master ]
|
|
paths:
|
|
- 'src/**'
|
|
- 'xtask/**'
|
|
- 'Cargo.toml'
|
|
- 'Cargo.lock'
|
|
- 'bundler.toml'
|
|
- 'check-branding.sh'
|
|
pull_request:
|
|
branches: [ master ]
|
|
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 nih_plug_template --release --features vst3
|