chore: setup tagging in GHA (#427)

* chore: setup tagging in GHA

* chore: easier releasing

* Update release.yml

* Update CONTRIBUTING.md

.github/workflows/release.yml

@@ -1,16 +1,22 @@
 # 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*.*.*"
 
 jobs:
   release:
-    uses: bazel-contrib/.github/.github/workflows/release_ruleset.yaml@v5
+    uses: bazel-contrib/.github/.github/workflows/release_ruleset.yaml@23b69a7ea7c1e36d0a92980d049ba72e6f4809f7 # https://github.com/bazel-contrib/.github/pull/19
     with:
       prerelease: false
       release_files: rules_lint-*.tar.gz
+      tag_name: ${{ inputs.tag_name }}

.github/workflows/tag.yaml

@@ -0,0 +1,41 @@
+# Tag a new release
+# 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 every Monday at 3PM UTC (8AM PST)
+  # NB: would prefer to trigger less frequently, perhaps bi-weekly, see
+  # https://medium.com/@VeselyCodes/bi-weekly-github-actions-7bea6be7bd96
+  schedule:
+    - cron: "0 15 * * 1"
+
+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@d3de774e9b607b079940a7a86952f44643743336 # v0.9.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'
+    permissions:
+      contents: write # allow create release

CONTRIBUTING.md

@@ -38,9 +38,23 @@ This means that any usage of `@rules_lint` on your system will point to this fol
 
 ## 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.
+If you do nothing, eventually the newest commits will be released automatically. See .github/workflows/tag.yaml.
+
+To trigger a release where the new version can be determined automatically from the commit history, just navigate to
+https://github.com/aspect-build/rules_lint/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.
 
 ## Recording a demo