Centralize shared DAW developer test tooling #1

Open
opened 2026-08-11 20:39:21 +02:00 by michael · 1 comment
Owner

Goal

Centralize DAW developer tooling that is currently copied across repositories into one public, shared repository.

Initial scope includes the common test helper (helpers.lua) and test runner (run_tests.sh). The repository should become the canonical maintenance point for reusable developer-side tooling that multiple DAW projects need.

Session rationale

The berhtjan 2.1 migration exposed that multiple DAW repositories currently carry different versions of the same test helpers and runner scripts. This creates drift, duplicated maintenance and inconsistent behavior between repositories.

A shared public developer-tool repository was therefore chosen instead of continuing to copy these files independently.

Scope

  • Establish daw-dev-tools as the public shared repository for reusable DAW developer tooling.
  • Move/canonicalize helpers.lua.
  • Move/canonicalize run_tests.sh.
  • Compare existing copies across DAW repositories and reconcile version differences before declaring the shared versions canonical.
  • Define a low-friction way for DAW repositories to consume the shared tooling without maintaining divergent local copies.
  • Document update/upgrade procedure for consuming repositories.
  • Keep runtime libraries separate: this repository is for developer/build/test tooling, not application runtime dependencies.

Acceptance criteria

  • Public repository daw-dev-tools exists.
  • Canonical helpers.lua is available and documented.
  • Canonical run_tests.sh is available and documented.
  • Existing divergent DAW copies have been compared and relevant differences reconciled.
  • At least one DAW repository consumes the centralized tooling successfully.
  • Lua 5.1 and Lua 5.4 test workflows remain supported where applicable.
  • Consumer/update workflow is documented.
  • Repository purpose clearly distinguishes developer tooling from runtime libraries.

Cross-repository impact

Initial consumers include DAW Lua/module repositories that currently carry their own copies of the test helper or runner. Migration of individual repositories should be tracked where concrete changes are required.

## Goal Centralize DAW developer tooling that is currently copied across repositories into one public, shared repository. Initial scope includes the common test helper (`helpers.lua`) and test runner (`run_tests.sh`). The repository should become the canonical maintenance point for reusable developer-side tooling that multiple DAW projects need. ## Session rationale The berhtjan 2.1 migration exposed that multiple DAW repositories currently carry different versions of the same test helpers and runner scripts. This creates drift, duplicated maintenance and inconsistent behavior between repositories. A shared public developer-tool repository was therefore chosen instead of continuing to copy these files independently. ## Scope - Establish `daw-dev-tools` as the public shared repository for reusable DAW developer tooling. - Move/canonicalize `helpers.lua`. - Move/canonicalize `run_tests.sh`. - Compare existing copies across DAW repositories and reconcile version differences before declaring the shared versions canonical. - Define a low-friction way for DAW repositories to consume the shared tooling without maintaining divergent local copies. - Document update/upgrade procedure for consuming repositories. - Keep runtime libraries separate: this repository is for developer/build/test tooling, not application runtime dependencies. ## Acceptance criteria - [ ] Public repository `daw-dev-tools` exists. - [ ] Canonical `helpers.lua` is available and documented. - [ ] Canonical `run_tests.sh` is available and documented. - [ ] Existing divergent DAW copies have been compared and relevant differences reconciled. - [ ] At least one DAW repository consumes the centralized tooling successfully. - [ ] Lua 5.1 and Lua 5.4 test workflows remain supported where applicable. - [ ] Consumer/update workflow is documented. - [ ] Repository purpose clearly distinguishes developer tooling from runtime libraries. ## Cross-repository impact Initial consumers include DAW Lua/module repositories that currently carry their own copies of the test helper or runner. Migration of individual repositories should be tracked where concrete changes are required.
Author
Owner

Decision 2026-10-03

Consumption model decided: shared tooling is embedded like daw-make-include under lib/daw/, not linked via symlink.

  • Libraries (common, net, berhtjan, ...): lib/ is a gitignored dev copy.
  • Host programs: embedded tooling is part of the program, so installation works without the developer's machine.
  • tool-gitea-workflow stays tooling and is not embedded.
  • Embedded libraries keep their tests, so missing external dependencies surface when testing the host program.

Additional notes:

  • Remove the debug print("map_ok:", ...) from helpers.lua during the move.
  • Symlinks to tool-gitea-workflow/src/helpers.lua currently exist in ~30 repos plus nested copies under lib/daw/*/test/.
  • Repository exists (README/LICENSE only); helpers.lua and run_tests.sh not yet moved.
## Decision 2026-10-03 Consumption model decided: shared tooling is **embedded like daw-make-include** under `lib/daw/`, not linked via symlink. - Libraries (common, net, berhtjan, ...): `lib/` is a gitignored dev copy. - Host programs: embedded tooling is part of the program, so installation works without the developer's machine. - `tool-gitea-workflow` stays tooling and is not embedded. - Embedded libraries keep their tests, so missing external dependencies surface when testing the host program. Additional notes: - Remove the debug `print("map_ok:", ...)` from `helpers.lua` during the move. - Symlinks to `tool-gitea-workflow/src/helpers.lua` currently exist in ~30 repos plus nested copies under `lib/daw/*/test/`. - Repository exists (README/LICENSE only); `helpers.lua` and `run_tests.sh` not yet moved.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
DAW/daw-dev-tools#1
No description provided.