Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
97 lines (72 loc) · 3.28 KB

CONTRIBUTING.md

File metadata and controls

97 lines (72 loc) · 3.28 KB

How to Contribute

All contributors are expected to follow the Code of Conduct.

Reporting Issues and Making Feature Requests

Please file issues and feature requests on the GitHub issue tracker: https://github.com/adbc-drivers/mysql/issues

Potential security vulnerabilities should be reported to security@adbc-drivers.org instead. See the Security Policy.

Build and Test

For basic development, the driver can be built and tested like any Go project. From the go/ subdirectory:

$ go build ./...
$ go test -tags assert -v ./...

This will not produce a shared library, however; that requires invoking the full build script. You will need pixi installed. From the repository root:

$ pixi run make

To run the validation suite, you will first need to build the shared library. You will also need to set up a MySQL instance (see the validation README). Finally, from the go/ subdirectory:

$ pixi run validate

This will produce a test report, which can be rendered into a documentation page (using MyST Markdown):

$ pixi run gendocs --output generated/

Then look at ./generated/mysql.md.

Opening a Pull Request

Before opening a pull request:

  • Review your changes and make sure no stray files, etc. are included.
  • Ensure the Apache license header is at the top of all files.
  • Check if there is an existing issue. If not, please file one, unless the change is trivial.
  • Assign the issue to yourself by commenting just the word take.
  • Run the static checks by installing pre-commit, then running pre-commit run --all-files from inside the repository. Make sure all your changes are staged/committed (unstaged changes will be ignored).

When writing the pull request description:

  • Ensure the title follows Conventional Commits format. The component should be go if it affects the Go driver, or it can be omitted for general maintenance (in general: it should be a directory path relative to the repo root, e.g. go/auth would also be valid if that directory existed). Example titles:

    • feat(go): support new data type
    • chore: update action versions
    • fix!:(go) return ns instead of us

    Ensure that breaking changes are appropriately flagged with a ! as seen in the last example above.

  • Make sure the bottom of the description has Closes #NNN, Fixes #NNN, or similar, so that the issue will be linked to your pull request.