Development guide

Overview

This guide is targeted at developers looking to contribute to Feast:

Learn How the Feast Contributing Process works.

Feast is composed of multiple components distributed into multiple repositories:

See also the CONTRIBUTING.md in the corresponding GitHub repository (e.g. main repo doc)

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

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

# Include -s flag to signoff
git commit -s -m "My first commit"

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

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 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.

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

Last updated 3 years ago