fix(ci): hand the built engine to the exe build, which no longer finds it

[davidp57]

Summary

2.0.0-rc7 published without ctld-tools.exe. PyInstaller failed with Unable to find D:\a\CTLD\CTLD\CTLD.lua when adding binary and data files — and the notes tell a Mission Maker the exe is the only file they need.

Root cause. build-exe runs on its own runner: it checks the repository out and goes straight to PyInstaller, which bundles the engine via --add-data "../../CTLD.lua;ctld_data". The release job does build CTLD.lua — on a different runner, with nothing passed between them. That only ever worked because the engine used to be committed, so the checkout carried it. CHORE-UNTRACK-BUILT-ENGINE (#110) git-ignored it, and rc7 is the first release published since, so the regression had never had an occasion to show.

#110 anticipated exactly this class of breakage and added an engine build to the python-quality job. release.yml was missed.

Fix. The release job uploads the CTLD.lua it just built as an artifact; build-exe downloads it before packaging. Chosen over rebuilding the engine a second time in build-exe, so the exe embeds byte-for-byte the same file attached to the release — two independent builds cannot guarantee that. if-no-files-found: error on the upload, so a missing engine fails the job that produced it rather than the one that consumes it.

Note on the smoke checks: release.yml already asserts the bundled engine is present in the exe ("a bundle that silently loses an --add-data entry must fail the release"). They never ran here — PyInstaller died before producing anything.

Test plan

• yaml.safe_load on the workflow; step order verified (download lands before the frontend build and PyInstaller)
• The download drops CTLD.lua at the workspace root, which is what ../../CTLD.lua resolves to from tools/ctld-tools
• CI green on this PR (does not exercise release.yml — only a tag push does)
• Real proof requires re-publishing the release; see the decision pending with the maintainer

Summary by Sourcery

CI:

• Update release workflow to upload CTLD.lua as an artifact and download it in the exe build job, failing early if the engine file is missing.

[sourcery-ai]

Reviewer's Guide

This PR fixes the release pipeline regression where the ctld-tools.exe build no longer finds CTLD.lua by passing the freshly built engine from the release job to the build-exe job via GitHub Actions artifacts, ensuring the exe embeds the same engine file that is attached to the release.

Sequence diagram for passing CTLD.lua from release job to build-exe

sequenceDiagram
    participant release_job
    participant artifact_storage
    participant build_exe_job
    participant pyinstaller

    release_job->>release_job: Build CTLD.lua
    release_job->>artifact_storage: actions_upload_artifact_v4(name=ctld-engine, path=CTLD.lua)
    build_exe_job->>artifact_storage: actions_download_artifact_v4(name=ctld-engine)
    build_exe_job->>pyinstaller: run_pyinstaller_add_data(../../CTLD.lua, ctld_data)
    pyinstaller-->>build_exe_job: ctld-tools.exe with embedded CTLD.lua

Loading

File-Level Changes

Change	Details	Files
Pass the built CTLD.lua from the release job to the build-exe job using GitHub Actions artifacts so PyInstaller can bundle the engine correctly.	Upload CTLD.lua as a short-retention artifact immediately after it is built in the release job, failing fast if the file is missing. Download the ctld-engine artifact in the build-exe job before the frontend build and PyInstaller steps so CTLD.lua is present at the workspace root for --add-data. Document in workflow comments that CTLD.lua is git-ignored and explain why artifact handoff is used instead of rebuilding the engine in build-exe.	.github/workflows/release.yml

---

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 reviewed your changes and they look great!

---

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.}