Skip to content

docs: contributing guideline#4347

Open
aldy505 wants to merge 2 commits into
masterfrom
aldy505/docs/contribution
Open

docs: contributing guideline#4347
aldy505 wants to merge 2 commits into
masterfrom
aldy505/docs/contribution

Conversation

@aldy505
Copy link
Copy Markdown
Collaborator

@aldy505 aldy505 commented May 23, 2026

No description provided.

@aldy505 aldy505 marked this pull request as ready for review May 23, 2026 08:12
@aldy505 aldy505 requested review from BYK and hubertdeng123 May 23, 2026 08:12
Comment thread CONTRIBUTING.md
Copy link
Copy Markdown
Collaborator

@aminvakil aminvakil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except .env.custom all are nitpicking really.

Comment thread CONTRIBUTING.md

## 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!
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Suggested change
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!

Comment thread CONTRIBUTING.md
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.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread CONTRIBUTING.md
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.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest using docker compose up --wait everywhere to be consistent with install.sh messages.

Suggested change
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.

Comment thread CONTRIBUTING.md
- 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.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to add "Take it easy though, focus on your development instead of commits" somehow, but I cannot think of a good sentence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants