ci(release): integrate release-please for automated semantic versioning

[rhysmcneill]

Closes #1092

Summary

This PR implements the release-please integration proposed in #1092, automating version determination, changelog generation, and release asset publishing for croc.

What this adds

File	Description
.github/workflows/release-please.yml	Core release-please workflow + full cross-platform build pipeline
release-please-config.json	release-please config (release-type: go, bootstrapped from v10.4.2)
.release-please-manifest.json	Version manifest starting at 10.4.2 — prevents any version regression
.github/workflows/release.yml	Updated with fixed action versions and workflow_dispatch input for manual use
.github/workflows/pr-title.yml	Enforces Conventional Commits format on PR titles (required for changelog accuracy)

How the release flow works

push to main
    └── release-please.yml
            ├── Opens/updates a "Release PR" with bumped version + CHANGELOG.md
            │       (PR updates continuously as new commits land on main)
            │
            └── When maintainer merges the Release PR:
                    ├── prepare-source  ->  source tarball with vendored deps
                    ├── build (matrix)  ->  20 platform/arch binaries (Windows, Linux, macOS, BSD)
                    └── release         ->  SHA256 checksums + all assets uploaded to GitHub Release

The maintainer retains full control — no release ships without an explicit merge.

All existing downstream workflows remain untouched

deploy.yml (Docker multi-arch) and winget.yml (Windows Package Manager) both trigger on release: types: [created] — they will continue to work exactly as today, fired by the release that release-please creates.

---

Maintainer prerequisites before merging

Before merging this PR, a few one-time repo settings changes are needed for release-please to work correctly. None of these require code changes.

1. Tag protection rule for v*

release-please creates and pushes tags like v10.4.3 directly. Without a tag protection rule, anyone with write access can push or delete release tags.

Settings -> Rules -> New ruleset:

• Target: tags matching v*
• Enable: Restrict deletions, Restrict updates
• Allow bypass for: github-actions[bot] (so release-please can push the tag)

2. Squash merging only (required for changelog)

release-please reads commit messages on main to determine the next version and generate CHANGELOG.md. It is mandatory that only squash merging is allowed. Squash merging ensures the PR title (which pr-title.yml enforces to be a valid Conventional Commit) becomes the single commit on main, giving clean and accurate changelogs. Merge commits and rebase merging must be disabled — if they are left enabled, noisy or non-conventional commits from PR branches will land on main and corrupt the changelog and version logic.

Settings -> General -> Pull Requests:

• Allow squash merging: enabled
• Default to PR title for squash merge commit message
• Allow merge commits: disabled
• Allow rebase merging: disabled

3. GitHub Actions permissions

release-please needs to open PRs and create releases.

Settings -> Actions -> General -> Workflow permissions:

• Select: Read and write permissions
• Allow GitHub Actions to create and approve pull requests

4. Adopt Conventional Commits (gradual)

The pr-title.yml workflow added in this PR enforces Conventional Commit format on PR titles. This can be introduced gradually — existing contributors will be prompted by the CI check.

Key prefixes and their effect on versioning:

• fix: — patch bump (e.g. v10.4.2 -> v10.4.3)
• feat: — minor bump (e.g. v10.4.2 -> v10.5.0)
• feat!: or BREAKING CHANGE: in body — major bump (e.g. v10.4.2 -> v11.0.0)
• chore:, docs:, ci:, refactor:, test: — no version bump (included in changelog only)

5. GITHUB_TOKEN permissions (already covered)

The release-please.yml workflow declares contents: write, issues: write, and pull-requests: write — no additional secrets or tokens are required beyond the default GITHUB_TOKEN.

---

Testing

I have tested this workflow on my own fork (rhysmcneill/croc) and the release-please action runs correctly — the Release PR is created with the right version bump and changelog entries. A full end-to-end test (i.e. merging the Release PR and validating the published artifacts) is not possible in isolation, as it would result in releasing actual build artifacts from a fork.

Test plan

• Merge this PR
• Apply the repo settings changes above (tag rule, squash merge, Actions permissions)
• Merge any subsequent fix: or feat: PR to main — release-please will open a Release PR within seconds
• Review the Release PR (check version bump and CHANGELOG.md content)
• Merge the Release PR — build pipeline runs, GitHub Release is created with all 20+ assets and checksums

---

If any issues arise when merged then ping me and we can look at it, however, as I outlined above, this works on my fork but I could not verify the release artifacts triggered since it would release genuine croc artifacts from a fork

[schollz]

how does this work?
what do I do?
also no sha pins, use tags

[rhysmcneill]

how does this work?

Did you see the workflow diagram at the top of my description - It shows how it works. Essentially, if a contributor creates a PR the title must follow the following format <type>(<scope>): <message> and when you merge it, this message is what is displayed in the CHANGELOG.md. The release-please automation is only triggered when a PR is merged to main and it will check the commit message for feat (minor), fix (patch) or feat! / BREAKING CHANGE (major). Release-please will create a PR for the next release (or update the existing PR) and then when you are ready to release the next version you just simply merge the Release-please PR.

It is a pretty simple workflow to follow - Would you like me to crate a RELEASE.md file, which explains the workflow for you and any other contributor?

what do I do?

You just need to review the PR, and make the adjustments that I outlined in the description. Afterwards, merge the PR and then from now on we will have automated release workflow. Of course, you have the final say on when a release happens since all you need to do is merge the release-please PR, which then triggers the build and publish for the artifacts.

also no sha pins, use tags

I dont understand what you mean by this - Release-please will create tags for each release in the format of vX.Y.Z.

---

Let me know if you need any further explanation / context - Happy to explain things further, or even jump on a call to discuss it.

Thanks!