Add release.yml: auto-tag and GitHub Release on push to master

[Copilot]

• Created .github/workflows/release.yml
• Fixed branch references from main to master
• Removed body from the GitHub Release step; release notes are now generated entirely by generate_release_notes: true

Original prompt

Create the release.yml file, here is our conversation for context.

Great — I can see your existing ci.yml. Here’s a deep dive on Option 2: GitHub Actions with Auto-Tagging + GitHub Releases, tailored specifically to your repo’s setup.

How Option 2 Works

The core idea is:

1. Every push to master triggers the workflow

2. It reads the latest Git tag (e.g., v1.2.3), increments it automatically (e.g., → v1.2.4)

3. It pushes the new tag to the repo

4. It creates a GitHub Release with auto-generated release notes

No changes to your C# or TypeScript code are required — versioning lives entirely in Git tags.

The Workflow File

This would be a new file alongside your existing ci.yml, so it won’t interfere with your current CI:

.github/workflows/release.yml

name: Release

on:
push:
branches: [master]

permissions:
contents: write # needed to push tags and create releases

jobs:
release:
name: Auto Version & Release
runs-on: ubuntu-latest
# Only run after CI passes (references your existing ci.yml jobs)
needs: [] # optionally add: [backend, frontend] if you merge workflows
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0 # IMPORTANT: fetches full tag history

  - name: Bump version and push tag
    id: tag
    uses: mathieudutour/github-tag-action@v6.2
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}
      default_bump: patch        # auto-bumps patch by default
      release_branches: master   # only tag on master

  - name: Create GitHub Release
    uses: softprops/action-gh-release@v2
    with:
      tag_name: ${{ steps.tag.outputs.new_tag }}
      name: Release ${{ steps.tag.outputs.new_tag }}
      body: ${{ steps.tag.outputs.changelog }}
      generate_release_notes: true

Key Things to Understand

🔢 Version Bumping Logic

The github-tag-action inspects your commit messages to decide the bump type:

Commit message containsBump typeExample result#major or BREAKING CHANGEMajorv1.0.0 → v2.0.0#minor or featMinorv1.0.0 → v1.1.0Anything elsePatch (default)v1.0.0 → v1.0.1So for most Dependabot PRs and bug fixes, you’ll just get a patch bump automatically.

📋 Auto-Generated Release Notes

GitHub’s generate_release_notes: true will automatically group your merged PRs and commits into the release body — no manual changelog writing needed.

🔐 Permissions

Your current ci.yml has permissions: contents: read globally. The new release.yml needs contents: write to push tags and create releases — keeping them as separate files is the right approach here.

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.

[Copilot]

Pull request overview

Adds a dedicated GitHub Actions workflow to automatically bump semver tags and publish GitHub Releases when changes are pushed to main, keeping release permissions scoped to this workflow.

Changes:

• Introduces .github/workflows/release.yml triggered on pushes to main
• Auto-tags using mathieudutour/github-tag-action@v6.2 and publishes a GitHub Release via softprops/action-gh-release@v2

[Copilot]

Releasing on every push to main without waiting for CI means this workflow can create/push a new tag and GitHub Release even when the CI workflow fails for the same commit. Consider triggering on workflow_run for the CI workflow (and gating on conclusion: success) or otherwise adding a CI-success gate before tagging/releasing.

[Xercius]

@copilot dont correct this, I like the way it's implemented. But do fix the reference to main, its master

[Copilot]

Fixed in 6e3f300 — both the on.push.branches trigger and release_branches are now master.

[Copilot]

This workflow can run concurrently on rapid successive pushes to main, which can race on "latest tag" calculation and cause one run to fail when pushing a tag/release that another run just created. Add a workflow-level concurrency group (e.g., one group for release on main) to serialize releases.

[Copilot]

softprops/action-gh-release is configured with both body and generate_release_notes: true. Depending on the action/GitHub API behavior, the provided body may override auto-generated notes (or produce confusing/double content). If the intent is GitHub auto-generated notes (per PR description), drop body; if the intent is the tag-action changelog, set generate_release_notes to false.

[Xercius]

@copilot drop body

[Copilot]

Done in 42d43ce — body removed; release notes are now sourced solely from generate_release_notes: true.