Development guide

Learn How the Feast Contributing Process works.

Project Structure

Feast is composed of multiple components distributed into multiple repositories:

Making a Pull Request

Incorporating upstream changes from master

Our preference is the use of git rebase instead of git merge : git pull -r

Signing commits

Commits have to be signed before they are allowed to be merged into the Feast codebase:

Good practices to keep in mind

• Fill in the description based on the default template configured when you first open the PR

  • What this PR does/why we need it

  • Which issue(s) this PR fixes

  • Does this PR introduce a user-facing change

• Include kind label when opening the PR

• Add WIP: to PR name if more work needs to be done prior to review

• Avoid force-pushing as it makes reviewing difficult

Managing CI-test failures

• GitHub runner tests

  • Click checks tab to analyse failed tests

• Prow tests

  • Visit to analyse failed tests

Feast Data Storage Format

Feast data storage contracts are documented in the following locations:

• Feast Offline Storage Format: Used by BigQuery, Snowflake (Future), Redshift (Future).

• Feast Online Storage Format: Used by Redis, Google Datastore.

Feast Protobuf API

Feast Protobuf API defines the common API used by Feast's Components:

• Feast Protobuf API specifications are written in proto3 in the Main Feast Repository.

• Changes to the API should be proposed via a GitHub Issue for discussion first.

Generating Language Bindings

The language specific bindings have to be regenerated when changes are made to the Feast Protobuf API: