Skip to content

Latest commit

 

History

History
103 lines (75 loc) · 4.29 KB

CONTRIBUTING.md

File metadata and controls

103 lines (75 loc) · 4.29 KB
Raw

How to contribute

There are a few guidelines that we need contributors to follow so that we are able to process requests as efficiently as possible. If you have any questions or concerns please feel free to contact us at [email protected].

Getting Started

  • Review our Code of Conduct
  • Submit the Individual Contributor License Agreement
  • Make sure you have a GitHub account
  • Submit a ticket for your issue, assuming one does not already exist.
    • Clearly describe the issue including steps to reproduce when it is a bug.
    • Make sure you fill in the earliest version that you know has the issue.
  • Fork the repository on GitHub

Making Changes

  • Create a feature branch off of main before you start your work.
    • Please avoid working directly on the main branch.
  • Setup the required package manager poetry
  • Setup the dev environment see below
  • Make commits of logical units.
    • You may be asked to squash unnecessary commits down to logical units.
  • Check for unnecessary whitespace with git diff --check before committing.
  • Write meaningful, descriptive commit messages.
  • Please follow existing code conventions when working on a file
  • Make sure to check the standards on the code see below
  • Install java 11 since it's required for unit tests while running 'make tests'
  • Make sure to test the code before you push changes see below

🤝 Submitting Changes

  • Push your changes to a topic branch in your fork of the repository.
  • Submit a pull request to the repository in the Nike-Inc organization.
  • After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity.
  • Bug fixes or features that lack appropriate tests may not be considered for merge.
  • Changes that lower test coverage may not be considered for merge.

📦 Package manager

We use make for managing different steps of setup and maintenance in the project. You can install make by following the instructions here

We use poetry as our package manager.

Please DO NOT use pip or conda to install the dependencies. Instead, use poetry:

make poetry-install

📌 Dev Environment Setup

To ensure our standards, make sure to install the required packages.

make dev

🧹 Linting and Standards

We use pylint, black and mypy to maintain standards in the codebase

make check

Make sure that the linter does not report any errors or warnings before submitting a pull request.

🧪 Testing

We use pytest to test our code. You can run the tests by running the following command:

make test

🧪 Integration Testing

  • Once you add a feature or a bug fix in brickflow, create a whl file from your feature branch
    • run 'poetry build' to generate the whl under the dist folder
  • Install brickflow from the whl file
    • pip install -whl file path-
  • Upload the whl file to Databricks workspace
    • Databricks Workspace --> Add --> Library
  • Copy the path of the uploaded whl file and paste it in the entrypoint.py as a Wheel Library
    • libraries=[ WheelTaskLibrary("dbfs:/FileStore/jars/dummy.whl") ],
  • Create a workflow and deploy it to make sure the feature or bug fix works as expected

Make sure that all tests pass before submitting a pull request.

🚀 Release Process

At the moment, the release process is manual. We try to make frequent releases. Usually, we release a new version when we have a new feature or bugfix. A developer with admin rights to the repository will create a new release on GitHub, and then publish the new version to PyPI.

Additional Resources