feat(ci): build and publish a dev exe on every merge (FEAT-DEV-BUILD-CHANNEL)

[davidp57]

Why

A release was the only thing that ever produced a ctld-tools.exe, so there was nothing to hand a tester between two of them — the gap FullGas ran into.

Zip's first idea was a special mode grafting an arbitrary CTLD.lua into a copy of the exe. It works (verified: 2.0.0-rc6 with 1.17 MB appended past its archive still runs — the PyInstaller bootloader finds its cookie regardless of trailing bytes) and was dropped anyway: a grafted exe pairs a new engine with the old schema, catalogue and interface, an unsigned exe altered after the build reads as tampered, and --version would keep naming the wrong build.

build-exe already produces a complete exe from a commit in 2 min 06 s on free public-repo runners. It only lacked a trigger.

What changed

• .github/workflows/dev-build.yml — on every push to develop (plus a manual trigger for any branch), builds the frontend, the stamped engine and the exe, then publishes it twice: an action artifact (14 days) and a floating dev pre-release. The second is not redundant: an artifact answers 401 to an anonymous download even on a public repo, and arrives zipped. The dev tag does not match published-v*, so it never re-triggers release.yml.
• merge_CTLD.ps1 -VersionSuffix — stamps the commit into the ctld.VERSION assignment, not just the header comment, so --version, the install report and the mission's copy of the engine all name the build. Local and release builds keep the version written in src/CTLD_config.lua. The suffix is restricted to [A-Za-z0-9._-]: it lands inside a Lua string literal.
• Docs — workflow.{md,fr.md} for developers; one sentence in ctld-tools.{md,fr.md} telling Mission Makers to take a dev build only when asked.

Verified locally

merge_CTLD.ps1 -VersionSuffix a1b2c3d
→ ctld.VERSION = "2.0.0-rc6-a1b2c3d"      (assignment + header)
→ resources.ctld_version() → 2.0.0-rc6-a1b2c3d
→ resources.docs_version() → dev          (help link unaffected)

A plain rebuild restores 2.0.0-rc6 byte for byte. configVersion is a separate value, so version-gap detection is untouched.

Ticket 01's acceptance cannot be checked before this merges — GitHub only runs a workflow from the default flow. Its first run will be this merge; the ticket says so rather than pretending otherwise.

Note: CTLD.lua is attached to the dev pre-release alongside the exe, which the ticket did not ask for — useful for anyone wiring a mission by hand, and free.

🤖 Generated with Claude Code

Summary by Sourcery

Introduce a dev build workflow that produces and publishes a tagged ctld-tools.exe on each merge to develop, and ensure dev builds embed their originating commit in the engine version while clarifying the dev channel in docs and backlog.

New Features:

• Add a GitHub Actions workflow that builds ctld-tools.exe on each push to develop and via manual trigger, publishing it both as an artifact and as a floating dev pre-release with attached CTLD.lua.

Enhancements:

• Extend the CTLD merge script to accept an optional version suffix, stamping it into ctld.VERSION in both header and merged source so dev builds can be identified by commit.
• Restrict the allowed characters for the version suffix to keep generated Lua string literals safe.
• Update developer and mission-maker documentation (EN/FR) to describe the dev build channel, its usage, and how it differs from releases.
• Mark FEAT-DEV-BUILD-CHANNEL backlog tickets as done or in progress and wire the lot to its feature branch in the backlog index.

CI:

• Add a Windows-based CI job that builds, smoke-checks, and publishes dev executables on merges to develop, with concurrency control to serialize updates to the floating dev tag.

Documentation:

• Document the dev build workflow and channel for developers, and explain dev builds to mission makers in both English and French.

Chores:

• Update acceptance checklists for dev build versioning and documentation tickets to reflect completed work and remaining runtime verifications.

[sourcery-ai]

Reviewer's Guide

Adds a CI workflow that builds and publishes a dev ctld-tools.exe on every merge to develop, extends the CTLD merge script to stamp a commit-based suffix into ctld.VERSION, and documents the new dev build channel for both developers and mission makers while updating backlog tickets and lot status.

Sequence diagram for the new dev-build CI workflow

sequenceDiagram
    actor Developer
    participant GitHub as GitHub
    participant DevBuildWorkflow as dev-build.yml
    participant MergeScript as merge_CTLD.ps1
    participant PyInstaller as pyinstaller
    participant GHCLI as gh

    Developer->>GitHub: Merge into develop
    GitHub-->>DevBuildWorkflow: Trigger dev-exe job

    DevBuildWorkflow->>DevBuildWorkflow: actions/checkout
    DevBuildWorkflow->>DevBuildWorkflow: setup-python / setup-node
    DevBuildWorkflow->>DevBuildWorkflow: npm ci && npm run build
    DevBuildWorkflow->>DevBuildWorkflow: poetry install --without dev --with build

    DevBuildWorkflow->>DevBuildWorkflow: Resolve suffix from GITHUB_SHA

    DevBuildWorkflow->>MergeScript: merge_CTLD.ps1 -VersionSuffix suffix
    MergeScript-->>DevBuildWorkflow: CTLD.lua with ctld.VERSION suffixed

    DevBuildWorkflow->>PyInstaller: pyinstaller ... ctld_tools/__main__.py
    PyInstaller-->>DevBuildWorkflow: ctld-tools.exe

    DevBuildWorkflow->>DevBuildWorkflow: ctld-tools.exe --version (smoke-check)

    DevBuildWorkflow->>GitHub: actions/upload-artifact ctld-tools-dev

    DevBuildWorkflow->>GHCLI: gh release delete dev
    DevBuildWorkflow->>GitHub: git tag -f dev && git push -f origin dev
    DevBuildWorkflow->>GHCLI: gh release create dev ctld-tools.exe CTLD.lua

Loading

File-Level Changes

Change	Details	Files
Introduce a dedicated dev-build GitHub Actions workflow that builds ctld-tools.exe from each develop commit and publishes it as both an artifact and a floating dev pre-release without interfering with the release workflow.	Create .github/workflows/dev-build.yml triggered on pushes to develop and manual dispatch, with concurrency to serialize dev builds. Install Node, Python, and Poetry, then build the web frontend and install ctld-tools with build extras before running the merge script. Derive a 7-character version suffix from the commit SHA and pass it to the merge script to stamp the dev build. Build ctld-tools.exe via PyInstaller embedding configs, CTLD.lua, and audio assets, then smoke-check that --version contains the expected suffix. Upload the exe as an ctld-tools-dev artifact (14-day retention) and recreate a dev prerelease tag and GitHub release with attached exe and CTLD.lua, ensuring the tag name does not match published-v*. Document in the dev release notes that the dev build is not a release and must be referenced by its printed version.	.github/workflows/dev-build.yml
Extend the CTLD merge PowerShell script to accept and validate a VersionSuffix, append it to ctld.VERSION in both the header and merged source, and keep local/release builds unaffected.	Add a param([string]$VersionSuffix="") block with help text explaining usage for dev builds versus local/release builds. Validate VersionSuffix against ^[A-Za-z0-9._-]+$ and hard-fail with a clear error message if it does not match, protecting the Lua string literal. After reading ctld.VERSION from CTLD_config.lua, append -$VersionSuffix when provided so the header comment uses the suffixed version. When merging source files, read each file into a string and, for dev builds, regex-rewrite the ctld.VERSION = "..." assignment to append the same suffix, so runtime --version and engine copies match the header. Keep behavior unchanged when VersionSuffix is empty so local and release builds still use the base version from CTLD_config.lua. Add comments explaining that dev builds are the only ones using VersionSuffix and that bug reports should name the suffixed version.	tools/build/merge_CTLD.ps1
Document the dev build channel, its usage, and constraints for developers and mission makers, and mark related backlog tickets as done or in progress.	Add a "Dev builds" section in docs/developer/workflow.md describing the dev-build workflow, dual publication (artifact + dev prerelease), version suffixing, and non-release status. Add the equivalent "Builds de développement" section in docs/developer/workflow.fr.md with mirrored content and warnings in French. Update mission-maker guides ctld-tools.md and ctld-tools.fr.md to mention dev builds, how to recognize them via suffixed version, and that they should only be used on request. Mark tickets 02-version-a-dev-build-by-its-commit.md and 03-document-the-channel.md as done, updating acceptance criteria details where verification is reasoned vs observed. Update ticket 01-build-the-exe-on-every-merge.md acceptance checklist to note that workflow behavior will be validated after first run and to include expectations for --version and release compatibility. Change the backlog README entry for FEAT-DEV-BUILD-CHANNEL from planned to in-progress and set its branch to feature/dev-build-channel. Ensure English and French documentation stay in sync and avoid wording that suggests dev builds supersede releases.	docs/developer/workflow.md docs/developer/workflow.fr.md docs/mission-maker/ctld-tools.md docs/mission-maker/ctld-tools.fr.md .backlog/FEAT-DEV-BUILD-CHANNEL/tickets/01-build-the-exe-on-every-merge.md .backlog/FEAT-DEV-BUILD-CHANNEL/tickets/02-version-a-dev-build-by-its-commit.md .backlog/FEAT-DEV-BUILD-CHANNEL/tickets/03-document-the-channel.md .backlog/README.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• The regex-based stamping of ctld.VERSION in merge_CTLD.ps1 will blindly append the suffix to any existing value each time it runs; consider making this idempotent (e.g., replacing with $ctldVersion or only stamping when the value matches the base version from CTLD_config.lua) to avoid double-suffixing on repeated builds.
• The dev-build workflow assumes gh is available on windows-latest; to avoid future breakage if the runner image changes, consider explicitly installing or validating the GitHub CLI before using it in the Refresh the floating dev pre-release step.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The regex-based stamping of `ctld.VERSION` in `merge_CTLD.ps1` will blindly append the suffix to any existing value each time it runs; consider making this idempotent (e.g., replacing with `$ctldVersion` or only stamping when the value matches the base version from `CTLD_config.lua`) to avoid double-suffixing on repeated builds.
- The dev-build workflow assumes `gh` is available on `windows-latest`; to avoid future breakage if the runner image changes, consider explicitly installing or validating the GitHub CLI before using it in the `Refresh the floating dev pre-release` step.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}