chore: add auto-release Downstreams https://github.com/bazel-contrib/rules-template/pull/129 Addresses https://github.com/bazel-contrib/rules_nodejs/discussions/3821 Also remove the bit about signing the Google CLA, which doesn't apply now that the repo was donated to Linux Foundation.
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 81d15b8..7f1c2ed 100644 --- a/.github/workflows/release.yml +++ b/.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 }}
diff --git a/.github/workflows/release_prep.sh b/.github/workflows/release_prep.sh index 34c4172..03d3300 100755 --- a/.github/workflows/release_prep.sh +++ b/.github/workflows/release_prep.sh
@@ -2,9 +2,9 @@ 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" @@ -12,9 +12,9 @@ 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
diff --git a/.github/workflows/tag.yaml b/.github/workflows/tag.yaml new file mode 100644 index 0000000..f88fe88 --- /dev/null +++ b/.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
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 64fc5fb..196f138 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md
@@ -13,28 +13,6 @@ 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.** @@ -42,9 +20,25 @@ to master when the PR is green and reviewed. The changes will then be in the next release. -### The small print +## Releasing -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). +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. + +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.