mirror of
https://github.com/bazel-contrib/bazel-lib
synced 2024-11-26 13:30:30 +00:00
48 lines
1.5 KiB
Markdown
48 lines
1.5 KiB
Markdown
# How to Contribute
|
|
|
|
## 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) (>= v3.2.0),
|
|
then run
|
|
|
|
```shell
|
|
pre-commit install
|
|
```
|
|
|
|
Otherwise later tooling on CI may yell at you about formatting/linting violations.
|
|
|
|
## Updating BUILD files
|
|
|
|
Some targets are generated from sources.
|
|
Currently this is just the `bzl_library` targets.
|
|
Run `bazel run //:gazelle` to keep them up to date.
|
|
|
|
## Using this as a development dependency of other rules
|
|
|
|
You'll commonly find that you develop in another WORKSPACE, such as
|
|
some other ruleset that depends on bazel_lib, or in a nested
|
|
WORKSPACE in the integration_tests folder.
|
|
|
|
To always tell Bazel to use this directory rather than some release
|
|
artifact or a version fetched from the internet, run this from this
|
|
directory:
|
|
|
|
```sh
|
|
OVERRIDE="--override_repository=bazel_lib=$(pwd)/bazel_lib"
|
|
echo "build $OVERRIDE" >> ~/.bazelrc
|
|
echo "query $OVERRIDE" >> ~/.bazelrc
|
|
```
|
|
|
|
This means that any usage of `@aspect_bazel_lib` on your system will point to this folder.
|
|
|
|
## Releasing
|
|
|
|
1. Make sure your git state is at the right place (something like `git fetch; git checkout origin/main`)
|
|
1. Determine the next release version, following semver (could automate in the future from changelog)
|
|
1. `git tag -a v1.2.3` (will open an editor to put release notes)
|
|
1. `git push --tags`
|
|
1. Watch the automation run on GitHub actions
|
|
1. Update the release page with auto-generated release notes
|