feat(cd): auto-tag releases twice a month (#129)

* feat(cd): auto-tag releases twice a month

Avoids the common pitfall where users have to request a release, i.e. the inevitable slack message
'hey could you cut a release with that new fix'

Relies on the repository using semver commit messages. This is already implied in this template because
commitizen-tools/commitizen is installed as a commit-msg pre-commit hook.

Based on https://github.com/aspect-build/rules_lint/pull/427/files where this is already observed to be working.

* Update release.yml

* fix: don't auto-release majors

* Delete MODULE.bazel.lock

* chore: this commit was tagged

.github/workflows/release.yml

@@ -1,9 +1,14 @@
 # Cut a release whenever a new tag is pushed to the repo.
-# You should use an annotated tag, like `git tag -a v1.2.3`
-# and put the release notes into the commit message for the tag.
 name: Release
 
 on:
+  # Can be triggered from the tag.yaml workflow
+  workflow_call:
+    inputs:
+      tag_name:
+        required: true
+        type: string
+  # Or, developers can manually push a tag from their clone
   push:
     tags:
       - "v*.*.*"
@@ -13,6 +18,7 @@ permissions:
 
 jobs:
   release:
-    uses: bazel-contrib/.github/.github/workflows/release_ruleset.yaml@v6
+    uses: bazel-contrib/.github/.github/workflows/release_ruleset.yaml@c9d6d1893b10a8d68584a6ba52c3dd35506486d0 # 2024-12-03
     with:
       release_files: rules_mylang-*.tar.gz
+      tag_name: ${{ inputs.tag_name }}

.github/workflows/tag.yaml

@@ -0,0 +1,43 @@
+# Tag a new release using https://github.com/marketplace/actions/conventional-commits-versioner-action
+#
+# This is easier than having to run manual `git` operations on a local clone.
+# It also runs on a schedule so we don't leave commits unreleased indefinitely
+# (avoiding users having to ping "hey could someone cut a release").
+
+name: Tag a Release
+on:
+  # Allow devs to tag manually through the GitHub UI.
+  # For example after landing a fix that customers are waiting for.
+  workflow_dispatch:
+
+  # Run twice a month, on the 1rst and 15th at 3PM UTC (8AM PST)
+  # This is a trade-off between making too many releases,
+  # which overwhelms BCR maintainers and over-notifies users,
+  # and releasing too infrequently which delays delivery of bugfixes and features.
+  schedule:
+    - cron: "0 15 1,15 * *"
+
+jobs:
+  tag:
+    permissions:
+      contents: write # allow create tag
+    runs-on: ubuntu-latest
+    outputs:
+      new-tag: ${{ steps.ccv.outputs.new-tag }}
+      new-tag-version: ${{steps.ccv.outputs.new-tag-version}}
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          # Need enough history to find the prior release tag
+          fetch-depth: 0
+      - name: Bump tag if necessary
+        id: ccv
+        uses: smlx/ccv@7318e2f25a52dcd550e75384b84983973251a1f8 # v0.10.0
+  release:
+    needs: tag
+    uses: ./.github/workflows/release.yml
+    with:
+      tag_name: ${{ needs.tag.outputs.new-tag-version }}
+    if: needs.tag.outputs.new-tag == 'true' && needs.tag.outputs.new-tag-version-type != 'major'
+    permissions:
+      contents: write # allow create release

CONTRIBUTING.md

@@ -44,6 +44,23 @@ This means that any usage of `@rules_mylang` on your system will point to this f
 
 ## Releasing
 
-1. Determine the next release version, following semver (could automate in the future from changelog)
-1. Tag the repo and push it (or create a tag in GH UI)
-1. Watch the automation run on GitHub actions
+Releases are automated on a cron trigger.
+The new version is determined automatically from the commit history, assuming the commit messages follow conventions, using
+https://github.com/marketplace/actions/conventional-commits-versioner-action.
+If you do nothing, eventually the newest commits will be released automatically as a patch or minor release.
+This automation is defined in .github/workflows/tag.yaml.
+
+Rather than wait for the cron event, you can trigger manually. Navigate to
+https://github.com/myorg/rules_mylang/actions/workflows/tag.yaml
+and press the "Run workflow" button.
+
+If you need control over the next release version, for example when making a release candidate for a new major,
+then: tag the repo and push the tag, for example
+
+```sh
+% git fetch
+% git tag v1.0.0-rc0 origin/main
+% git push origin v1.0.0-rc0
+```
+
+Then watch the automation run on GitHub actions which creates the release.