Commit Graph

5 Commits

Author SHA1 Message Date
mikkeli d107127017 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
mikkeli 7a92485cf1 ci: path-filter the pull_request trigger too
The push trigger was already restricted to master and to source paths,
but pull_request carried only a branch filter — so a PR touching nothing
but the README would have run a full build. A branch filter constrains
where a workflow fires, not what fires it.

Both filters now list the same six paths. A docs-only change runs nothing,
on either trigger.

Note that .github/workflows/** is deliberately absent from both lists, so
editing this file does not run it. That is the intended trade: fewer
pointless builds, at the cost of a broken workflow surfacing on the next
source change rather than immediately.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
2026-09-04 19:26:35 +09:00
mikkeli 3a144064e3 feat: adopt the template's branding toolkit
Replaces the single check-branding.sh with the four-file toolkit from
musiikki/nih-plug-template, moved under tools/ alongside where the deploy
scripts will eventually live.

The two scripts are byte-identical to the template's; everything specific
to this plugin lives in tools/branding.conf and tools/branding-sites.tsv.
That is the point of the split: syncing an improvement is now a file copy
rather than a shell merge, which is what the last two syncs had become.

This repo's data differs from the template's in ways that exercise the
design rather than fight it: params live in src/params.rs rather than
src/lib.rs, deploy.ps1 exists so its three rows check instead of skip, and
the CI bundle command carries no --features flag because VST3 is always on
here. All of that is table data now, not forked shell.

Nothing needed overriding: PKG, STRUCT and PARAMS_STRUCT all derive
correctly from PLUGIN_NAME ("Bari 206" -> bari_206 / Bari206 /
Bari206Params). AUTHOR is pinned because this plugin separates the person
who wrote it from the organisation that vends it — a distinction the
template could not express until integrating here surfaced it.

Adopting it required two upstream fixes, both made in the template first
so the scripts stay identical: cargo AUTHOR as a value distinct from
Plugin::VENDOR, and site patterns narrowed to the smallest distinctive
fragment after this repo's rustfmt-wrapped CLAP_DESCRIPTION proved a
statement-spanning pattern cannot match correctly formatted source.

CI is repointed at tools/check-branding.sh, and its path filter widened to
tools/** — the old filter named a file that no longer exists, so a change
to the toolkit would have triggered no CI at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
2026-09-02 16:39:12 +09:00
Mikkeli Matlock 37f34e1175 rename: Codename 206 -> Bari 206
Retires the working codename now rather than at 1.0, because the two identity
constants a DAW uses to recognise a plugin across sessions can only be changed
for free while nothing has saved a project with it. Verified: zero references
to the plugin across all 69 FL project backups, under any identity string.

Derived spellings:
    Cargo package     codename_206        -> bari_206
    bundle / DAW name Codename 206 |
                      206 prototype       -> Bari 206      (unified; drops "prototype")
    Rust types        Codename206(Params) -> Bari206(Params)
    CLAP_ID           com.mikkeli.codename-206
                                          -> org.novoyuuparosk.bari-206
    VST3_CLASS_ID     Codename206Maxi!    -> Bari206Multiband

CLAP_ID moves to reverse-DNS on a domain actually controlled, and stops
disagreeing with a VENDOR that was already Novoyuuparosk. VST3_CLASS_ID stays
exactly 16 bytes and drops "Maxi", which sat close to Image-Line's Maximus and
Maximizer in the same product category.

Author identity converges on Mikkeli Matlock <mikkeli@novoyuuparosk.org>;
Cargo authors had been carrying a personal gmail address while Plugin::EMAIL
already used the org one. VENDOR stays Novoyuuparosk, which is the org rather
than the person, and copyright stays with the person.

Deliberately unchanged: the repo, its remote, the local directory and the
homepage URL all keep "codename-206". Renaming those buys nothing and costs a
Gitea rename, a remote rewrite and a directory move, so the bare "codename-206"
is current branding rather than residue - and is the one spelling the STALE
list must not contain.

Driven by check-branding.sh rather than by grep: setting the canonical block
listed all 26 sites, including .github/workflows/ci.yaml, which no explicit
check covered. That gap is now closed by a positive check on the CI bundle
command, so a future rename fails in seconds instead of after a full compile.
STALE now carries both the retired and the new spellings, so the next rename
is self-checking too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LU1NRL7fAaZTtFMTTPn2b1
2026-08-31 22:55:41 +09:00
mikkeli 193cee0aef ci: gate pushes on a build, test and bundle
Migrated from musiikki/nih-plug-template, adapted for this repo: the
template gates VST3 behind an opt-in `vst3` feature and so builds twice,
while this plugin always ships VST3 (nih_plug is taken with its default
features), so one build covers both formats.

The branding check runs first because it needs no toolchain and finishes
in under a second, so a half-landed rename fails before a build is spent
on it. The bundle step is included because `cargo build` never exercises
the xtask bundler, and bundler.toml drifting from the crate name stays
invisible until you try to produce an artifact.

Performance is deliberately not gated. `Plugin::process()` cannot be
called from a test — `ProcessContext` requires a `&Transport`, whose
constructor and fields are `pub(crate)` to nih_plug — so any realtime
check would have to target the `src/dsp/` types directly, and a meaningful
one needs an audio deadline rather than a shared CI box.

Verified by running the exact step sequence as the gitea-runner user under
the service's environment: 28 branding checks, 20 unit tests, both bundles
produced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
2026-08-31 22:34:31 +09:00