| Want to contribute? Great! First, read this page (including the small print at the end). |
| |
| ## Formatting |
| |
| Starlark files should be formatted by buildifier. |
| We suggest using a pre-commit hook to automate this. |
| First [install pre-commit](https://pre-commit.com/#installation), |
| then run |
| |
| ```shell |
| pre-commit install |
| ``` |
| |
| Otherwise the Buildkite CI will yell at you about formatting/linting violations. |
| |
| ### 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. |
| |
| ## 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. |
| |
| 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. |
