chore: add auto-release

Downstreams bazel-contrib/rules-template#129
Addresses #3821

Also remove the bit about signing the Google CLA, which doesn't apply now that the repo was donated to Linux Foundation.

Author: alexeagle

.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*.*.*"
-
+permissions:
+  contents: write
 jobs:
   release:
-    uses: bazel-contrib/.github/.github/workflows/release_ruleset.yaml@v6
+    uses: bazel-contrib/.github/.github/workflows/release_ruleset.yaml@0b644c3ee5c7cd9a7657f7e782b26a599d9b6d5c # 2025-01-23
     with:
       prerelease: false
       release_files: rules_nodejs-*.tar.gz
+      tag_name: ${{ inputs.tag_name }}

.github/workflows/release_prep.sh

@@ -2,19 +2,19 @@
 
 set -o errexit -o nounset -o pipefail
 
-# Set by GH actions, see
-# https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables
-TAG=${GITHUB_REF_NAME}
+# Argument provided by reusable workflow caller, see
+# https://github.com/bazel-contrib/.github/blob/d197a6427c5435ac22e56e33340dff912bc9334e/.github/workflows/release_ruleset.yaml#L72
+TAG=$1
 # The prefix is chosen to match what GitHub generates for source archives
 PREFIX="rules_nodejs-${TAG:1}"
 ARCHIVE="rules_nodejs-$TAG.tar.gz"
 git archive --format=tar --prefix="${PREFIX}/" "${TAG}" | gzip > "$ARCHIVE"
 SHA=$(shasum -a 256 "$ARCHIVE" | awk '{print $1}')
 
 cat << EOF
-## Using Bzlmod with Bazel 6
+## Using Bzlmod with Bazel 6 or greater
 
-1. Enable with \`common --enable_bzlmod\` in \`.bazelrc\`.
+1. (Bazel 6 only) Enable with \`common --enable_bzlmod\` in \`.bazelrc\`.
 2. Add to your \`MODULE.bazel\` file:
 
 \`\`\`starlark

.github/workflows/tag.yaml

@@ -0,0 +1,41 @@
+# 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 3rd and 18th 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 3,18 * *"
+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

@@ -13,38 +13,32 @@ pre-commit install
 
 Otherwise the Buildkite CI will yell at you about formatting/linting violations.
 
-### Before you contribute
-
-**Before we can use your code, you must sign the
-[Google Individual Contributor License Agreement](https://developers.google.com/open-source/cla/individual?csw=1)
-(CLA)**, which you can do online.
-
-The CLA is necessary mainly because you own the copyright to your changes,
-even after your contribution becomes part of our codebase, so we need your
-permission to use and distribute your code. We also need to be sure of
-various other things  for instance that you'll tell us if you know that
-your code infringes on other people's patents. You don't have to sign
-the CLA until after you've submitted your code for review and a member has
-approved it, but you must do it before we can put your code into our codebase.
-
-Before you start working on a larger contribution, you should get in touch
-with us first. Use the issue tracker to explain your idea so we can help and
-possibly guide you.
-
-**Before starting a complex contribution we strongly encourage you to share a design document**.
-
-[Here](https://goo.gl/YCQttR) you can find a document template.
-
 ### Code reviews and other contributions.
 
 **All submissions, including submissions by project members, require review.**
 We use GitHub's code review system to suggest changes, then merge the changes
 to master when the PR is green and reviewed. The changes will then be in the
 next release.
 
-### The small print
+## Releasing
+
+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/bazel-contrib/rules_nodejs/actions/workflows/tag.yaml
+and press the "Run workflow" button.
 
-Contributions made by corporations are covered by a different agreement than
-the one above, the
-[Software Grant and Corporate Contributor License Agreement](https://cla.developers.google.com/about/google-corporate).
+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.