Development guide
Overview
This guide is targeted at developers looking to contribute to Feast:
Learn How the Feast Contributing Process works.
Project Structure
Feast is composed of multiple components distributed into multiple repositories:
Making a Pull Request
See also the CONTRIBUTING.md in the corresponding GitHub repository (e.g. main repo doc)
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 PRAdd
WIP:
to PR name if more work needs to be done prior to reviewAvoid
force-pushing
as it makes reviewing difficult
Managing CI-test failures
GitHub runner tests
Click
checks
tab to analyse failed tests
Prow tests
Visit Prow status page 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:
Last updated