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:
Hosts all required code to run Feast. This includes the Feast Python SDK and Protobuf definitions. For legacy reasons this repository still contains Terraform config and a Go Client for Feast.
Java-specific Feast components. Includes the Feast Core Registry, Feast Serving for serving online feature values, and the Feast Java Client for retrieving feature values.
Feast Spark SDK & Feast Job Service for launching ingestion jobs and for building training datasets with Spark
Helm Chart for deploying Feast on Kubernetes & Spark.
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 signoffgit 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
kind label when opening the PR
WIP: to PR name if more work needs to be done prior to review
force-pushing as it makes reviewing difficult
Managing CI-test failures
GitHub runner tests
checks tab to analyse failed tests
Visit Prow status page to analyse failed tests
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: