CONTRIBUTING.md

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, then run

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 rules_oci, 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_oci=$(pwd)/rules_oci"
echo "build $OVERRIDE" >> ~/.bazelrc
echo "query $OVERRIDE" >> ~/.bazelrc

This means that any usage of @rules_oci 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/bazel-contrib/rules_oci/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.