Coexisting with semantic-release

• semantic-release: what version is this release? It reads conventional commits, decides the next version, writes the changelog, tags, and publishes.
• zerv: what version is this exact Git state? It computes a version for any commit on any branch. The builds semantic-release never sees.

​

On main: semantic-release, then zerv

jobs:
    semantic-release:
        uses: ./.github/workflows/shared-semantic-release.yml

    zerv-versioning:
        needs: semantic-release
        if: needs.semantic-release.outputs.is_valid_semantic_release == 'true'
        uses: ./.github/workflows/shared-zerv-versioning.yml

• The semantic-release job publishes and tags releases (new_release_version, new_release_published outputs). The job succeeds on every push to main, even when nothing is released: on a non-release commit with no tag on HEAD, new_release_version is empty and new_release_published is false. The zerv-versioning job runs on every valid semantic-release run, via the if: gate shown above.
• The zerv-versioning job (GitHub Actions) versions the current build for artifact naming, including on commits semantic-release skips because no new release was published.

uses: ./.github/workflows/shared-zerv-versioning.yml
with:
    overridden_tag_version: ${{ needs.semantic-release.outputs.new_release_version }}

​

On pull requests: zerv alone

# on: pull_request
jobs:
    zerv-versioning:
        needs: check-pre-release
        uses: wislertt/zerv/.github/workflows/shared-zerv-versioning.yml@v0.8.19
        with:
            schema: ${{ (needs.check-pre-release.outputs.is_valid == 'true' && 'standard-base-prerelease-post') || '' }}

    tag-pre-release:
        needs: [zerv-versioning, check-pre-release]
        if: needs.check-pre-release.outputs.is_valid == 'true'
        uses: wislertt/zerv/.github/workflows/shared-create-tags.yml@v0.8.19
        with:
            tags: '["${{ fromJson(needs.zerv-versioning.outputs.versions).v_semver }}"]'

    deploy-all-env:
        needs: zerv-versioning
        uses: ./.github/workflows/deploy-all-env.yml
        with:
            semver: ${{ fromJson(needs.zerv-versioning.outputs.versions).semver }}
            pep440: ${{ fromJson(needs.zerv-versioning.outputs.versions).pep440 }}
            docker_tag: ${{ fromJson(needs.zerv-versioning.outputs.versions).docker_tag }}

​

Choosing where each applies

• Release flow (changelog, publish, tag): semantic-release. zerv has no opinion and no tooling for it.
• Continuous artifact versioning (docker tags on every push, deploy manifests on PR previews): zerv. semantic-release only versions release commits.
• Non-conventional commit histories: zerv works from tags and distance alone, so it drops in without retraining your team on commit message format.

​

Where to go next

• Why zerv - the complementary positioning story
• GitHub Actions - the reusable versioning workflow
• zerv-flow - working demo repo for both halves of this split