If you are using devcontainers and/or codespaces then you can start contributing immediately and skip the next step.
Starlark files should be formatted by buildifier. We suggest using a pre-commit hook to automate this. First install pre-commit, then run
pre-commit installOtherwise later tooling on CI will yell at you about formatting/linting violations.
Some targets are generated from sources.
Currently this is just the bzl_library targets.
Run bazel run //:gazelle to keep them up-to-date.
You'll commonly find that you develop in another WORKSPACE, such as some other ruleset that depends on rules_mylang, 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:
OVERRIDE="--override_repository=rules_mylang=$(pwd)/rules_mylang"
echo "common $OVERRIDE" >> ~/.bazelrcThis means that any usage of @rules_mylang on your system will point to this folder.
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/myorg/rules_mylang/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
% git fetch
% git tag v1.0.0-rc0 origin/main
% git push origin v1.0.0-rc0Then watch the automation run on GitHub actions which creates the release.