Thanks for your interest in contributing to SQLBoiler!
We have a very lightweight process and aim to keep it that way. Read the sections for the piece you're interested in and go from there.
If you need quick communication we're usually on Slack.
- Open PR against dev branch with explanation
- Participate in Github Code Review
For code that requires little to no discussion, please just open a pull request with some explanation against the dev branch. All code goes through dev before going out in a release.
- Start proposal of idea in Github issue
- After design concensus, open PR with the work against the dev branch
- Participate in Github Code Review
If however you're working on something bigger, it's usually better to check with us on the idea before starting on a pull request, just so there's no time wasted in redoing/refactoring or being outright rejected because the PR is at odds with the design. The best way to accomplish this is to open an issue to discuss it. It can always start as a Slack conversation but should eventually end up as an issue to avoid penalizing the rest of the users for not being on Slack. Once we agree on the way to do something, then open the PR against the dev branch and we'll commence code review with the Github code review tools. Then it will be merged into dev, and later go out in a release.
-
Add a Configuration files.
-
Write your changes
-
Generate executable. Run again if you have changed anything in core code or driver code.
./boil.sh build all
-
Also Move sqlboiler-[driver] built to the bin of gopath if you have changed the driver code.
-
Generate your models from existing tables
./boil.sh gen [driver]
-
You may need to install following package before able to run the tests.
go get -u github.com/volatiletech/null
-
Test the output
./boil.sh test
Issues should be filed on Github, simply use the template provided and fill in detail. If there's more information you feel you should give use your best judgement and add it in, the more the better. See the section below for information on providing database schemas.
Bugs that have responses from contributors but no action from those who opened them after a time will be closed with the comment: "Stale"
A database schema can help us fix generation issues very quickly. However not everyone is willing to part with their database schema for various reasons and that's fine. Instead of providing the schema please then provide a subset of your database (you can munge the names so as to be unrecognizable) that can help us reproduce the problem.
Note: Your schema information is included in the output from --debug
, so be careful giving this
information out publicly on a Github issue if you're sensitive about this.