Contribute

How to Contribute

All contributions are welcome! There are many ways to contribute to this project:

  • File a new issue for a bug report or feature request.
  • Improve the documentation or add new examples.
  • Participate in discussions and reviews.

Using devcontainers

If you are using devcontainers and/or codespaces then you can start contributing immediately and skip the next step.

Formatting

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 install

Otherwise later tooling on CI will 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 rules_pandoc, 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_pandoc=$(pwd)/rules_pandoc"
echo "common $OVERRIDE" >> ~/.bazelrc

This means that any usage of @rules_pandoc on your system will point to this folder.

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/drklein-rk/rules_pandoc/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-rc0

Then watch the automation run on GitHub actions which creates the release.