2019-04-05 15:10:34 +00:00
|
|
|
# Contribution guidelines
|
|
|
|
|
|
2019-05-08 18:19:32 +00:00
|
|
|
Contributions are welcome! Please open an Issues or Pull Request for any changes.
|
|
|
|
|
|
|
|
|
|
In addition to core contributions, developers are encouraged to build their own custom transformers which
|
2019-04-05 15:10:34 +00:00
|
|
|
can be run together with other custom transformers using the [composeAndExeucte](../../staging/documentation/composeAndExecute.md) command.
|
|
|
|
|
|
2019-05-08 18:19:32 +00:00
|
|
|
## Pull Requests
|
|
|
|
|
- `go fmt` is run as part of `make test` and `make integrationtest`, please make sure to check in the format changes.
|
|
|
|
|
- Ensure that new code is well tested, including integration testing if applicable.
|
|
|
|
|
- Make sure the build is passing.
|
|
|
|
|
- Update the README or any [documentation files](./) as necessary. If editing the Readme, please
|
|
|
|
|
conform to the
|
|
|
|
|
[standard-readme specification](https://github.com/RichardLitt/standard-readme).
|
|
|
|
|
- You may merge a Pull Request once you have an approval from core developer.
|
|
|
|
|
|
2019-04-05 15:10:34 +00:00
|
|
|
## Creating a new migration file
|
|
|
|
|
1. `make new_migration NAME=add_columnA_to_table1`
|
|
|
|
|
- This will create a new timestamped migration file in `db/migrations`
|
|
|
|
|
1. Write the migration code in the created file, under the respective `goose` pragma
|
|
|
|
|
- Goose automatically runs each migration in a transaction; don't add `BEGIN` and `COMMIT` statements.
|
2019-05-08 18:19:32 +00:00
|
|
|
1. Core migrations should be committed in their `goose fix`ed form. To do this, run `make version_migrations` which
|
|
|
|
|
converts timestamped migrations to migrations versioned by an incremented integer.
|
