docs: contributing guideline#4347
Conversation
aminvakil
left a comment
There was a problem hiding this comment.
Except .env.custom all are nitpicking really.
|
|
||
| ## What to contribute | ||
|
|
||
| Hi! I'm Reinaldy (aldy505). I view self-hosted Sentry not just as something we maintain, but as a community we develop together. Contributing to self-hosted means more than code contributions; there are many ways to help! |
There was a problem hiding this comment.
I don't think it's appropriate to mention your name on CONTRIBUTING.md of a organization project honestly :) But that's just me, as I just haven't seen it anywhere before. If you feel this is more welcoming, ignore this.
| Hi! I'm Reinaldy (aldy505). I view self-hosted Sentry not just as something we maintain, but as a community we develop together. Contributing to self-hosted means more than code contributions; there are many ways to help! | |
| Hi! We view self-hosted Sentry not just as something we maintain, but as a community we develop together. Contributing to self-hosted means more than code contributions; there are many ways to help! |
| Generated and managed config files live in the repo working tree: | ||
|
|
||
| - `.env` is the default environment file. | ||
| - `.env.custom` is loaded automatically when present and should be your normal place for local overrides. |
There was a problem hiding this comment.
This does not get picked up by docker compose automatically, you should use something like this for it to get passed to containers:
docker compose --env-file .env --env-file .env.custom up --wait
| There are two kinds of tests: | ||
|
|
||
| 1. Unit tests: run specific bash scripts and ensure they're working as intended. Test files are under the `_unit-test/` directory, and assertions are made using Bash. | ||
| 2. Integration tests: run the entire self-hosted stack (using specific `COMPOSE_PROFILES`) by running `./install.sh` and `docker compose up -d`, then execute scenarios for logging in and verifying that events are ingested and queried correctly. Test files are under `_integration-test/`, and assertions are written in Python using the `pytest` testing framework. |
There was a problem hiding this comment.
I'd suggest using docker compose up --wait everywhere to be consistent with install.sh messages.
| 2. Integration tests: run the entire self-hosted stack (using specific `COMPOSE_PROFILES`) by running `./install.sh` and `docker compose up -d`, then execute scenarios for logging in and verifying that events are ingested and queried correctly. Test files are under `_integration-test/`, and assertions are written in Python using the `pytest` testing framework. | |
| 2. Integration tests: run the entire self-hosted stack (using specific `COMPOSE_PROFILES`) by running `./install.sh` and `docker compose up --wait`, then execute scenarios for logging in and verifying that events are ingested and queried correctly. Test files are under `_integration-test/`, and assertions are written in Python using the `pytest` testing framework. |
| - Call out any generated files, config migrations, or operator-visible behavior changes. | ||
| - Include the exact validation you ran locally. | ||
| - Link upstream issues or PRs when the root cause is outside this repository. | ||
| - Keep commit history readable. A small number of focused commits is better than a long stream of fixups. |
There was a problem hiding this comment.
I want to add "Take it easy though, focus on your development instead of commits" somehow, but I cannot think of a good sentence.
No description provided.