131868bdca
Major security, observability, and configuration improvements:
## Security Hardening
- Implemented configurable CORS (no more wildcards)
- Added comprehensive auth middleware for admin endpoints
- Enhanced webhook HMAC validation
- Added input validation and rate limiting
- Security headers and CSP policies
## Configuration Management
- Made N8N webhook URL configurable (WHOOSH_N8N_BASE_URL)
- Replaced all hardcoded endpoints with environment variables
- Added feature flags for LLM vs heuristic composition
- Gitea fetch hardening with EAGER_FILTER and FULL_RESCAN options
## API Completeness
- Implemented GetCouncilComposition function
- Added GET /api/v1/councils/{id} endpoint
- Council artifacts API (POST/GET /api/v1/councils/{id}/artifacts)
- /admin/health/details endpoint with component status
- Database lookup for repository URLs (no hardcoded fallbacks)
## Observability & Performance
- Added OpenTelemetry distributed tracing with goal/pulse correlation
- Performance optimization database indexes
- Comprehensive health monitoring
- Enhanced logging and error handling
## Infrastructure
- Production-ready P2P discovery (replaces mock implementation)
- Removed unused Redis configuration
- Enhanced Docker Swarm integration
- Added migration files for performance indexes
## Code Quality
- Comprehensive input validation
- Graceful error handling and failsafe fallbacks
- Backwards compatibility maintained
- Following security best practices
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
81 lines
3.9 KiB
Markdown
81 lines
3.9 KiB
Markdown
# 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](https://nats.io/contributing/) 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](https://github.com/nats-io/nats.go/issues/new/choose) 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/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](https://github.com/nats-io/nats.go/blob/main/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](https://github.com/nats-io/nats.go/discussions), join the [NATS Slack](https://slack.nats.io/), or
|
|
send your question to the [NATS Google Group](https://groups.google.com/forum/#!forum/natsio).
|
|
|
|
## Testing
|
|
|
|
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:
|
|
|
|
```shell
|
|
go mod tidy -modfile=go_test.mod
|
|
```
|
|
|
|
To the tests you can pass `-modfile=go_test.mod` flag to `go test` or instead you can also set `GOFLAGS="-modfile=go_test.mod"` as an environment variable:
|
|
|
|
```shell
|
|
go test ./... -modfile=go_test.mod
|
|
```
|