Version Builder

A GitHub Action that generates a semantic version number based on an input version (or package.json), the current branch, and the number of commits since package.json last changed. It appends a preid suffix (e.g. dev.5) on designated branches and emits both semver and non-semver variants as outputs.

• If the version input is not provided, the action reads version from the repository's package.json.
• Any existing pre-release suffix on the incoming version is stripped before processing (e.g. 1.0.0-rc.0 → base 1.0.0), so re-running on the same base version never produces a double-preid like 1.0.0-rc.0-rc.5.
• The branch is checked against the following rules in order:
  1. force-stable: true → always stable, regardless of branch.
  2. force-preid: true → always pre-release, uses the mapped preid for the branch or falls back to preid.
  3. Exact match in preid-branches → pre-release with the mapped preid (e.g. main → rc, develop → dev).
  4. Matches a stable-branches regex pattern (e.g. v1, 1.x) → stable.
  5. All other branches → pre-release with the default preid (e.g. feature/foo → dev).
• When pre-release, the commit count since the last package.json change is appended: 1.5.6 → 1.5.6-dev.5. The counter resets to 0 on every version bump.
• When stable, the version is emitted unchanged: 1.5.6
• A tag output is always emitted: pre-release builds use the preid label (e.g. rc, dev); stable builds emit latest for the highest semver branch and v{major}-lts for older ones (detected via git ls-remote).
• On stable branches, when on-version-conflict is not ignore (the default), the exact version's git tag is checked before it's emitted: fail stops the action if the tag already exists, bump-patch auto-increments the patch until a free tag is found. Git tags are the source of truth — nothing is committed back to package.json.

steps:
  - name: Checkout
    uses: actions/checkout@v4
    with:
      fetch-depth: 0 # required for accurate commit counting

  - name: Build version
    id: version
    uses: sketch7/version-builder-action@v3
    with:
      version: "1.5.6" # optional — omit to read from package.json
      preid: "dev" # optional, default fallback preid
      preid-branches: "main:rc,master:rc,develop:dev,vnext:next" # optional
      stable-branches: "^v\\d+$,^\\d+\\.x$" # optional

  - name: Use outputs
    run: |
      echo "Version:          ${{ steps.version.outputs.version }}"
      echo "File version:     ${{ steps.version.outputs.fileVersion }}"
      echo "Preid:            ${{ steps.version.outputs.preid }}"
      echo "Preid counter:    ${{ steps.version.outputs.preidCounter }}"
      echo "Tag:              ${{ steps.version.outputs.tag }}"
      echo "Is pre-release:   ${{ steps.version.outputs.isPrerelease }}"

- name: Build version (stable)
  uses: sketch7/version-builder-action@v3
  with:
    force-stable: "true"

- name: Build version (always preid)
  uses: sketch7/version-builder-action@v3
  with:
    force-preid: "true"
    preid: "rc"

- name: Build version
  uses: sketch7/version-builder-action@v3
  with:
    stable-branches: "^v\\d+$,^\\d+\\.x$,^hotfix/.*$"

Protects against merging two release branches before a version bump lands — otherwise both would resolve to the same stable version and the second publish would fail partway through the build. Opt-in; the default (ignore) never checks tags, so this is fully backward compatible.

- name: Build version
  uses: sketch7/version-builder-action@v3
  with:
    on-version-conflict: "bump-patch" # or "fail" to stop instead of bumping

- name: Build version
  uses: sketch7/version-builder-action@v3
  with:
    package-json-dir: "apps/client"

Releases are handled entirely by the Release workflow — no local tooling needed.

1. Bump the version — update version in package.json, commit, and push to main.
2. Trigger the workflow — go to Actions → Release → Run workflow and click Run.

The workflow will automatically:

• Read the version from package.json on the triggered branch.
• Create the exact semver tag (e.g. v1.2.3) and update the floating major tag (e.g. v1).
• Create the v1 branch if it doesn't exist yet, or update it for minor/patch releases within the same major.
• Publish a GitHub Release with auto-generated release notes.