[Copilot]

The repository had no automated process for producing and attaching compiled binaries to GitHub Releases, and the existing CI only built for Linux with a gh release create step that would fail on pre-existing releases.

Changes

New: .github/workflows/release.yml

• Triggers on release: published (automatic) and workflow_dispatch with a tag input (manual, for populating existing releases like v0.0.1-alpha)
• Matrix builds on ubuntu-latest and macos-latest in parallel (fail-fast: false)
• Packages output as openwarcraft3-linux-x64.tar.gz / openwarcraft3-macos-x64.tar.gz (binary + shared libs)
• Uploads to the target GitHub Release via gh release upload --clobber — idempotent, safe to re-run

on:
  release:
    types: [published]
  workflow_dispatch:
    inputs:
      tag:
        description: 'Release tag to attach assets to (e.g. v0.0.1-alpha)'
        required: true

Permissions scoped to contents: write at the job level only.

Modified: .github/workflows/c-cpp.yml

Removed the gh release create step to eliminate conflicts when both workflows run on a tag push. CI now strictly builds and uploads workflow artifacts.

Modified: README.md

Added a Releases section documenting how release assets are produced and how to manually re-trigger the workflow against an existing tag.

Original prompt

Add GitHub Actions rules to automatically build and upload compiled executables to GitHub Releases for the repository corepunch/openwarcraft3.

Context:

• A release exists but has no compiled executables: https://github.com/corepunch/openwarcraft3/releases/tag/v0.0.1-alpha
• Desired targets for now: ubuntu-latest and macos-latest.

Requirements:

1. Create a GitHub Actions workflow that runs on GitHub release events (published) and builds the project on:
   • ubuntu-latest
   • macos-latest
2. The workflow must upload build artifacts as release assets to the corresponding GitHub Release (not just as workflow artifacts).
3. The workflow should be written so it can be re-run manually (workflow_dispatch) to attach assets to an existing release/tag (e.g., v0.0.1-alpha), ideally by accepting a tag input.
4. Detect the repo’s actual build system and implement correct build steps accordingly (e.g., CMake, Make, etc.). Use best practices for caching dependencies if applicable.
5. Name and package the output executables appropriately per OS (e.g., tar.gz/zip) and include OS/arch in filenames.
6. Document in README (or a short doc) how releases are produced and how to re-run the workflow to populate an existing release.

Acceptance criteria:

• After merging, publishing a new release results in release assets (compiled executables) being attached automatically for Ubuntu and macOS.
• The workflow can be manually triggered to upload assets to the existing v0.0.1-alpha release.

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.