Files

T

jochen e1f5d4fdf0 Vendor every dependency, so no build fetches the host's validator (hq to-be 45 D1)

The controller imports mesh-host/validate through a replace onto the forge
that holds it, and every build — the build agent's go build in a fresh
toolchain container, the Dockerfile's go mod download — would have fetched
it through the public proxy and checksum database at build time: a merge
breaking main on the network, the class Phase 1 removes. vendor/ is
committed; go builds from it with nothing fetched, and refuses to build
when it and go.mod disagree, so a pin moved without go mod vendor fails at
once. The Dockerfile copies vendor/ and builds with GOPROXY=off.

2026-10-06 10:29:10 +02:00

4.2 KiB

Raw Blame History

Contributing

Thanks for your interest in contributing! This document contains nats-io/nats.go specific contributing details. If you are a first-time contributor, please refer to the general NATS Contributor Guide to get a comprehensive overview of contributing to the NATS project.

Getting started

There are three general ways you can contribute to this repo:

Proposing an enhancement or new feature
Reporting a bug or regression
Contributing changes to the source code

For the first two, refer to the GitHub Issues which guides you through the available options along with the needed information to collect.

Contributing changes

Prior to opening a pull request, it is recommended to open an issue first to ensure the maintainers can review intended changes. Exceptions to this rule include fixing non-functional source such as code comments, documentation or other supporting files.

Proposing source code changes is done through GitHub's standard pull request workflow.

If your branch is a work-in-progress then please start by creating your pull requests as draft, by clicking the down-arrow next to the Create pull request button and instead selecting Create draft pull request.

This will defer the automatic process of requesting a review from the NATS team and significantly reduces noise until you are ready. Once you are happy, you can click the Ready for review button.

Guidelines

A good pull request includes:

A high-level description of the changes, including links to any issues that are related by adding comments like Resolves #NNN to your description. See Linking a Pull Request to an Issue for more information.
An up-to-date parent commit. Please make sure you are pulling in the latest main branch and rebasing your work on top of it, i.e. git rebase main.
Unit tests where appropriate. Bug fixes will benefit from the addition of regression tests. New features will not be accepted without suitable test coverage!
No more commits than necessary. Sometimes having multiple commits is useful for telling a story or isolating changes from one another, but please squash down any unnecessary commits that may just be for clean-up, comments or small changes.
No additional external dependencies that aren't absolutely essential. Please do everything you can to avoid pulling in additional libraries/dependencies into go.mod as we will be very critical of these.

Sign-off

In order to accept a contribution, you will first need to certify that the contribution is your original work and that you license the work to the project under the Apache-2.0 license.

This is done by using Signed-off-by statements, which should appear in both your commit messages and your PR description. Please note that we can only accept sign-offs under a legal name. Nicknames and aliases are not permitted.

To perform a sign-off with git, use git commit -s (or --signoff).

Get help

If you have questions about the contribution process, please start a GitHub discussion, join the NATS Slack, or send your question to the NATS Google Group.

Testing

The integration tests run against real NATS servers spawned by a tester service. Locally it runs inside the test binary (github.com/synadia-io/orbit.go/ntf), so no docker is needed; CI uses the synadia/ntf-server docker image instead. See TESTING.md for the full workflow; the short version:

make test                            # full race-enabled suite, no docker
make test T=TestName PKG=./test/...  # iterate on a single test

Nothing to install or start.

You should use go_test.mod to manage your testing dependencies. Please use the following command to update your dependencies and avoid changing the main go.mod in a PR:

go mod tidy -modfile=go_test.mod

4.2 KiB Raw Blame History