Learn GitHub Actions - Automated Release Management & Semantic Versioning

#Introduction

In episode 17 we installed environment protection rules and an approval gateway. All that security ultimately leads to one important moment: the release. Manually deciding versions like v1.2.3 then v1.2.4 is often miscounted, inconsistent between developers, and lets changelogs pile up uncontrolled. In this episode we hand version numbering, changelogs, and GitHub Release creation entirely over to automation.

In this episode we discuss:

1. The concepts of Semantic Versioning (SemVer) and Conventional Commits.
2. Version numbering automation with release-please and semantic-release.
3. A release workflow that creates a GitHub Release with changelog and artifacts.

#Semantic Versioning: The Agreed Version-Naming Language

SemVer uses the MAJOR.MINOR.PATCH format. The analogy: MAJOR is like a car generation — going from generation 1 to 2 can mean a totally different engine; MINOR is like added features within the same generation; PATCH is like small fixes to existing features. These numbers aren't decoration; they tell consumers how "dangerous" the update is for them.

If a version is bumped incorrectly, consumers can be disappointed. Raising MAJOR without reason forces them to re-review the entire API; skipping it silently breaks their applications on upgrade.

#Conventional Commits: The Source of Truth for Version Numbering

Automation needs "feed" that's machine-readable. Conventional Commits is a commit message format convention that exposes the type of change via a prefix:

Examples: feat: tambah endpoint healthcheck, fix: perbaiki memory leak pada worker, and feat!: ganti format response API. Because it's these prefixes the versioner reads, commit message discipline becomes an absolute prerequisite. Without it, the pipeline is "deaf" to code changes and versions never go up.

#The Two Most Popular Tools: release-please vs semantic-release

Two tools dominate the ecosystem: release-please (from Google) and semantic-release (community). Both read Conventional Commits, compute the next version, and write a changelog. The difference is in their working style:

release-please opens a pull request containing changes to the CHANGELOG.md file and version bumps in the manifest. Once that PR is merged, it creates the tag and GitHub Release — humans still hold control over when a release happens. semantic-release is the opposite: the moment code enters main, it immediately tags the version and releases. Suitable for teams that want full automation without extra review.

#Automatic Release Workflow with release-please

The following workflow runs on every push to main. On a feature commit push, it creates or updates the Release PR; on a push of the merged Release PR, it publishes the tag and GitHub Release:

name: Release Automation
 
on:
  push:
    branches: [main]
 
permissions:
  contents: write
  pull-requests: write
 
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - name: Jalankan release-please
        uses: google-github-actions/release-please-action@v4
        with:
          release-type: node
          token: ${{ secrets.GITHUB_TOKEN }}

Things to note:

• permissions: contents: write and pull-requests: write are needed to create tags, releases, and Release PRs.
• release-type: node tailors the behavior to Node.js projects; python, go, java, and simple are also available.
• The action uses a token from the secrets.GITHUB_TOKEN context, so all its changes are audited as part of the repository.

How the cycle works: developer merges a feature → the action creates a "chore(main): release v1.1.0" PR → the team reviews → the PR is merged → the action detects its release PR was merged → creates the v1.1.0 tag and GitHub Release. As a result, releases are always documented and easy to trace.

#Attaching Artifacts to GitHub Releases with softprops

For binaries, installers, or other assets, softprops/action-gh-release@v2 attaches files to a release. This workflow is triggered by a v-prefixed tag and uploads the build output:

name: Attach Release Assets
 
on:
  push:
    tags: ['v*']
 
permissions:
  contents: write
 
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout kode
        uses: actions/checkout@v4
 
      - name: Build artifact
        run: npm ci && npm run build
 
      - name: Buat/update GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          files: dist/*.zip
          generate_release_notes: true

Explanation:

• generate_release_notes: true makes GitHub compile release notes from the commits merged since the previous release.
• files: dist/*.zip attaches all zip files in the dist folder; it can also be a glob array.
• The tags: ['v*'] event makes this workflow run only when a v tag is created, so it never triggers double releases.

A common production pattern: release-please creates the tag and release, then the tag-triggered workflow attaches artifacts to the existing release. Both run sequentially without overwriting each other.

#Conclusion

In this episode we automated release management & semantic versioning:

• SemVer (MAJOR.MINOR.PATCH) provides a version language understood by both machines and humans.
• Conventional Commits become the source of truth for determining the next version.
• release-please uses a Release PR; semantic-release releases directly from main.
• A workflow on push to main generates tags and GitHub Releases automatically.
• softprops/action-gh-release attaches artifacts to tag-triggered releases.

A good production pipeline doesn't just run smoothly — it also has to be easy to trace when it fails. In episode 19 we discuss troubleshooting, debugging, and custom action development, including enabling debug logging and SSH-ing into the runner. See you there!