Build it with us

pg-regression-radar is open source and small enough to read in an afternoon. Break it on your own Postgres, fix a typo, review a pull request or take on a real issue. All of it counts, and you don't need anyone's permission to start.

Find a first issue Join the Discord Read the guide

Ways to help

No code neededRun it on your PostgresPoint it at a real database and tell us what breaks, what confuses you, or what's missing.Report a bug → No code neededFix or write docsA typo, an unclear step, a missing example. Docs changes are the easiest first pull request.Open the docs folder → CodeTake a good first issueScoped for newcomers, with context and a place to start. Say in a comment that you're on it.See the issues → ReviewReview a pull requestRead a diff, run it, say what you found. A fresh pair of eyes is one of the most useful things you can give.Open pull requests → IdeaPropose a featureHave a case the radar misses? Describe the query or the deploy that slipped through.Request a feature → CommunityHelp someone get unstuckAnswer a question, or share how you run it. Setups from real clusters teach us the most.Join the discussions →

Your first pull request

01

Fork and clone

Fork the repository on GitHub, then clone your copy.

git clone https://github.com/<you>/pg-regression-radar
cd pg-regression-radar

02

Check it builds

The unit tests need no database or cluster.

go build ./... && go vet ./... && go test ./...

03

Branch and commit

Conventional Commits, signed off with -s.

git switch -c fix/short-description
git commit -s -m "fix(collector): short summary"

04

Open the pull request

Push the branch and open the PR. CI checks the title, the sign-off, formatting and tests, and a maintainer takes it from there.

git push -u origin fix/short-description

A small fix? Just open the pull request. Something bigger? Open an issue first so we agree on the approach before you write it. The full guide covers branch names, tests, docs and release notes, and our testing and CI/CD pages show what runs on your PR.

What to expect

Talk first for big changes

Typos and bounded fixes can go straight to a pull request. Anything larger starts as an issue, which saves you from writing code that needs a different design.

CI does the checking

Formatting, vet, tests, sign-off and the PR title run on every pull request. From a fork, a maintainer may need to approve the first run and add a label for the slower integration suites.

Messy commits are fine

Pull requests are squash-merged, so only the PR title ends up in history. Commit as often as you like while you iterate.

Come say hi

Chatpg_regression_radar on DiscordAsk a question, show your setup, or get unblocked while you work on a pull request. No question is too basic.Join the server → ForumGitHub DiscussionsLonger questions and ideas, written down where anyone can search for them later.Browse discussions →

Contributors

Everyone who has shipped code to the project.

Everyone taking part follows the Code of Conduct.