Add tag-triggered release workflow with develop-branch safety check and tag-aligned versioning

[Copilot]

Adds an automated GitHub Actions release pipeline that builds and publishes the NSIS installer when a v* tag is pushed, with guards to ensure releases only originate from develop.

New: .github/workflows/release.yml

• Triggers on v* tag pushes
• Safety gate: verifies the tagged commit is reachable from origin/develop via git merge-base --is-ancestor; aborts before publishing if not
• Auto-detects vMAJOR.MINOR.PATCH-beta.N tags → prerelease: true; all other v* tags are stable releases
• Build process mirrors build.yml: checkout with submodules, NSIS via Chocolatey, CMake configure + package
• Publishes a GitHub Release with auto-generated notes and uploads the NSIS .exe as the sole asset using softprops/action-gh-release@v2

Updated: CMakeLists.txt

At configure time, git describe --tags --exact-match HEAD is used to detect a tagged build. If the tag matches vMAJOR.MINOR.PATCH[-beta.N], it overrides PROJECT_VERSION_* so that CPACK_PACKAGE_VERSION (and therefore the installer filename) reflects the tag exactly — including the -beta.N suffix.

# Non-tag builds fall back to hardcoded defaults (1.2.0)
find_package(Git QUIET)
if(GIT_FOUND)
  execute_process(
    COMMAND ${GIT_EXECUTABLE} describe --tags --exact-match HEAD
    ...
    OUTPUT_VARIABLE GIT_TAG ...)
  if(GIT_TAG MATCHES "^v([0-9]+)\\.([0-9]+)\\.([0-9]+)(-beta\\.[0-9]+)?$")
    set(PROJECT_VERSION_MAJOR ${CMAKE_MATCH_1})
    ...
    set(PROJECT_VERSION "...${CMAKE_MATCH_4}")  # includes -beta.N when present
  endif()
endif()

Original prompt

Add an automated GitHub Actions release workflow for AgOpenGPS-Official/AOG-TaskController that builds and publishes NSIS installer releases from the develop branch when version tags are pushed.

Requirements:

• Create a new workflow file at .github/workflows/release.yml on the develop branch.
• Trigger: on push of tags matching v*.
• Ensure safety: the workflow must verify the tag’s commit is reachable from origin/develop; if not, fail the job (do not publish a release).
• Packaging: replicate the existing build process used in .github/workflows/build.yml:
  • checkout with submodules recursive
  • install NSIS via Chocolatey
  • cmake configure: cmake -S . -B build -DBUILD_EXAMPLES=OFF -DBUILD_TESTING=OFF -Wno-dev
  • build/package: cmake --build build --config Release --target package
  • locate resulting NSIS installer exe under build/_CPack_Packages/win64/NSIS/*.exe
• Publishing:
  • Create a GitHub Release for the tag and upload the NSIS installer exe as a release asset.
  • Use permissions: contents: write.
  • Release name should be the tag name.
  • Generate release notes (generate_release_notes: true).
  • Set prerelease automatically:
    • If the tag matches semantic version beta tags in the form vMAJOR.MINOR.PATCH-beta.N, mark as prerelease.
    • Non-beta tags (e.g., v1.2.0) are stable releases.
• Versioning consistency:
  • Update CMakeLists.txt so that when building from a git tag matching vMAJOR.MINOR.PATCH-beta.N or vMAJOR.MINOR.PATCH, the CPack/package version is derived from the tag (so the installer version aligns with the release tag).
  • For non-tag builds, keep current behavior (use PROJECT_VERSION_MAJOR/MINOR/PATCH).
  • The existing PROJECT_VERSION_MAJOR/MINOR/PATCH values can remain as defaults, but tag builds should override PROJECT_VERSION and CPACK_PACKAGE_VERSION appropriately.

Acceptance checks:

• Pushing tag v1.2.0 on a commit that is on develop publishes a stable release and attaches exactly one NSIS installer exe.
• Pushing tag v1.3.0-beta.1 on a commit that is on develop publishes a prerelease and attaches the NSIS installer exe.
• Pushing a tag that is not on develop fails before publishing.
• CPack/NSIS installer version matches the tag version (including beta suffix when applicable).

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Would you able to assist me in creating a workflow to do Task Controller RELEASES?

Assistant: Yes — I can help you set up a GitHub Actions “Release” workflow for AgOpenGPS-Official/AOG-TaskController that:

• builds the Windows NSIS installer (same way your current Build workflow does),
• then creates (or updates) a GitHub Release and uploads the installer as a Release asset.

What you have today (in develop)

You currently have:

• .github/workflows/build.yml: builds on push to main/develop and on PRs; uploads an artifact named “Windows Installer” from build/_CPack_Packages/win64/NSIS/*.exe.
• CMakeLists.txt: version is hard-coded as 1.2.0 via PROJECT_VERSION_* and is also used by CPack/NSIS packaging.

That’s perfect to base a Release workflow on.

---

Recommended release approach (simple + reliable)

Trigger releases from git tags

Create releases when you push a tag like:

• v1.2.0
• v1.2.1

This is the most common pattern and avoids accidentally releasing from random commits.

---

Workflow file to add: .github/workflows/release.yml

This workflow:

1. runs only when you push a v* tag
2. builds the installer
3. creates a GitHub Release for that tag
4. uploads the .exe installer to the Release

name: Release

on:
  push:
    tags:
      - "v*"

permissions:
  contents: write  # required to create releases + upload assets

jobs:
  windows_release:
    name: Windows Release (NSIS)
    runs-on: windows-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive
          fetch-depth: 0  # helpful for tags/versioning

      - name: Install NSIS
        run: choco install nsis -y

      - name: Configure (CMake)
        run: |
          mkdir build
          cmake -S . -B build -DBUILD_EXAMPLES=OFF -DBUILD_TESTING=OFF -Wno-dev

      - name: Build + Package (CPack/NSIS)
        run: cmake --build build --config Release --target package

      - name: Find installer
        shell: pwsh
        run: |
          $installer = Get-ChildItem -Path "build/_CPack_Packages/win64/NSIS" -Filter *.exe -Recurse | Select-Object -First 1
          if (-not $installer) { throw "Installer .exe not found" }
          "INSTALLER_PATH=$($installer.FullName)" | Out-File -FilePath $env:GITHUB_ENV -Append
          "INSTALLER_NAME=$($installer.Name)" | Out-File -FilePath $env:GITHUB_ENV -Append
          Write-Host "Found installer: $($installer.FullName)"

      - name: Create GitHub Release
        id: create_release
      ...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for you](https://github.com/AgOpenGPS-Official/AOG-TaskController/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo.

[gunicsba]

@GwnDaan could you please check this? So we could maybe create somewhat regular releases?