docs/project/development-guide.md
This guide is targeted at developers looking to contribute to Feast components in the main Feast repository:
Please see this page for more details on the structure of the entire codebase.
The compatibility policy for Feast can be found here, and should be followed for all changes proposed, by maintainers or contributors.
See Contribution process and Community for details on how to get more involved in the community.
We use the convention that the assignee of a PR is the person with the next action.
If the assignee is empty it means that no reviewer has been found yet. If a reviewer has been found, they should also be the assigned the PR. Finally, if there are comments to be addressed, the PR author should be the one assigned the PR.
PRs that are submitted by the general public need to be identified as ok-to-test. Once enabled, Prow will run a range of tests to verify the submission, after which community members will help to review the pull request.
A quick list of things to keep in mind as you're making changes:
git pull on your PR branchfeat: or fix: or ci: or chore: or docs:). Keep in mind that any PR with feat: or fix: will directly make it into the change log of a release, so make sure they are understandable!kind/bug or kind/housekeeping)) or else checks will fail.NONE in that field if there are no user facing changes.docs/ that impacts the area you are contributing to.WIP: to PR name if more work needs to be done prior to reviewFork the Feast Github repo and clone your fork locally. Then make changes to a local branch to the fork.
See Creating a pull request from a fork
Setup pre-commit to automatically lint and format the codebase on commit:
pre-commit and hooks:make install-precommit
make format and make lint.:warning: Warning: using the default integrations with IDEs like VSCode or IntelliJ will not sign commits. When you submit a PR, you'll have to re-sign commits to pass the DCO check.
Use git signoffs to sign your commits. See https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification for details
Then, you can sign off commits with the -s flag:
git commit -s -m "My first commit"
GPG-signing commits with -S is optional.
Our preference is the use of git rebase [master] instead of git merge : git pull -r.
Note that this means if you are midway through working through a PR and rebase, you'll have to force push:
git push --force-with-lease origin [branch name]
make is used to run various scriptsuv venv --python 3.11 (Replace the python version with your desired version)source venv/bin/activatemake install-python-dependencies-devTo build the UI from the latest released NPM package (hosted under @feast-dev/feast-ui):
make build-ui
If you want to test backend and frontend together using 'feast ui' command and with a locally built Feast UI package, you can build using:
make build-ui-local
Use this when you are making changes to the React UI code and want to see them live via the backend.
Recompile python lock files. This only needs to be run when you make changes to requirements or simply want to update python lock files to reflect latest versions.
make lock-python-dependencies-all
make compile-protos-python
docker build -t docker-whale -f ./sdk/python/feast/infra/feature_servers/multicloud/Dockerfile .
Feast Python SDK and CLI codebase:
mypyruff (see isort (I) rules)ruffTo ensure your Python code conforms to Feast Python code standards:
make format-python
make lint-python
Setup pre-commit hooks to automatically format and lint on commit.
Unit tests (pytest) for the Feast Python SDK and CLI can run as follows:
make test-python-unit
:warning: Local configuration can interfere with Unit tests and cause them to fail:
- Ensure no AWS configuration is present > and no AWS credentials can be accessed by
boto3- Ensure Feast Python SDK and CLI is not configured with configuration overrides (ie
~/.feast/configshould be empty).
There are two sets of tests you can run:
For this approach of running tests, you'll need to have docker set up locally: Get Docker
It leverages a file based offline store to test against emulated versions of Datastore, DynamoDB, and Redis, using ephemeral containers.
These tests create new temporary tables / datasets locally only, and they are cleaned up. when the containers are torn down.
make test-python-integration-local
To test across clouds, on top of setting up Redis, you also need GCP / AWS / Snowflake setup.
Note: you can manually control what tests are run today by inspecting RepoConfiguration and commenting out tests that are added to
DEFAULT_FULL_REPO_CONFIGS
GCP
PROJECT_ID and your key.json. These will be your secrets that you will need to configure in Github actions. Namely, secrets.GCP_PROJECT_ID and secrets.GCP_SA_KEY. The GCP_SA_KEY value is the contents of your key.json file.objectCreator, objectViewer, objectAdmin, and admin, so that your tests can use the bucket.gcloud auth login
gcloud auth application-default login
gcloud auth application-default login, you should see some output of the form:
Credentials saved to file: [$HOME/.config/gcloud/application_default_credentials.json]
export GOOGLE_APPLICATION_CREDENTIALS="$HOME/.config/gcloud/application_default_credentials.json” to add the application credentials to your .zshrc or .bashrc.export GCLOUD_PROJECT=[your project id from step 2] to your .zshrc or .bashrc.gcloud config list should give you something like this:$ gcloud config list
[core]
account = [your email]
disable_usage_reporting = True
project = [your project id]
Your active configuration is: [default]
export GCS_REGION='[your gcs region e.g US]'
export GCS_STAGING_LOCATION='[your gcs staging location]'
NOTE: Your GCS_STAGING_LOCATION should be in the form gs://<bucket name> where the bucket name is from step 2.
AWS
export AWS_REGION='[your aws region]'
export AWS_CLUSTER_ID='[your aws cluster id]'
export AWS_USER='[your aws user]'
export AWS_DB='[your aws database]'
export AWS_STAGING_LOCATION='[your s3 staging location uri]'
export AWS_IAM_ROLE='[redshift and s3 access role]'
export AWS_LAMBDA_ROLE='[your aws lambda execution role]'
export AWS_REGISTRY_PATH='[your aws registry path]'
Snowflake
ACCOUNTADMIN (if you created your own account, you should be), give yourself the SYSADMIN role.grant role accountadmin, sysadmin to user user2;
FEAST with the schemas OFFLINE and ONLINE.create or replace warehouse feast_tests_wh with
warehouse_size='MEDIUM' --set your warehouse size to whatever your budget allows--
auto_suspend = 180
auto_resume = true
initially_suspended=true;
create or replace database FEAST;
use database FEAST;
create schema OFFLINE;
create schema ONLINE;
FEAST_S3.export SNOWFLAKE_CI_DEPLOYMENT='[your snowflake account name]'
export SNOWFLAKE_CI_USER='[your snowflake username]'
export SNOWFLAKE_CI_PASSWORD='[your snowflake pw]'
export SNOWFLAKE_CI_ROLE='[your CI role e.g. SYSADMIN]'
export SNOWFLAKE_CI_WAREHOUSE='[your warehouse]'
export BLOB_EXPORT_STORAGE_NAME='[your data unloading storage name]'
export BLOB_EXPORT_URI='[your data unloading blob uri]`
Note that for Snowflake / GCP / AWS, running make test-python-integration will create new temporary tables / datasets in your cloud storage tables.
gcp, aws, and snowflake) or don't need to run against all of the online stores, you can tag your test with specific providers or stores that you need(@pytest.mark.universal_online_stores or @pytest.mark.universal_online_stores with the only parameter). The only parameter selects specific offline providers and online stores that your test will test against. Example:# Only parametrizes this test with the sqlite online store
@pytest.mark.universal_online_stores(only=["sqlite"])
def test_feature_get_online_features_types_match():
-k parameter. The parametrized integration tests are all uniquely identified by their provider and online store so the -k option can select only the tests that you need to run. For example, to run only Redshift related tests, you can use the following command:python -m pytest -n 8 --integration -k Redshift sdk/python/tests
Test across clouds requires existing accounts on GCP / AWS / Snowflake, and may incur costs when using these services.
For this approach of running tests, you'll need to have docker set up locally: Get Docker
It's possible to run some integration tests against emulated local versions of these services, using ephemeral containers. These tests create new temporary tables / datasets locally only, and they are cleaned up. when the containers are torn down.
The services with containerized replacements currently implemented are:
You can run make test-python-integration-container to run tests against the containerized versions of dependencies.
You can run make test-python-universal-spark to run all tests against the Spark offline store. (Note: you'll have to run make install-python-dependencies-dev first).
Not all tests are passing yet
You can run make test-python-universal-trino to run all tests against the Trino offline store. (Note: you'll have to run make install-python-dependencies-dev first)
You can run test-python-universal-postgres-offline to run all tests against the Postgres offline store. (Note: you'll have to run make install-python-dependencies-dev first)
You can run test-python-universal-postgres-online to run all tests against the Postgres offline store. (Note: you'll have to run make install-python-dependencies-dev first)
TODO
See also development instructions related to the helm chart below at Developing the Feast Helm charts
There are 2 helm charts:
Generally, you can override the images in the helm charts with locally built Docker images, and install the local helm chart.
All README's for helm charts are generated using helm-docs. You can install it
(e.g. with brew install norwoodj/tap/helm-docs) and then run make build-helm-docs.
See the Java demo example (it has development instructions too using minikube) here
It will:
make build-java-docker-dev to build local Java feature server binariesapplication-override.yaml to override the image tag to use the locally built dev images.helm install feast-release ../../../infra/charts/feast --values application-override.yamlSee the Python demo example (it has development instructions too using minikube) here
It will:
make build-feature-server-dev to build a local python feature server binaryhelm install feast-release ../../../infra/charts/feast-feature-server --set image.tag=dev --set feature_store_yaml_base64=$(base64 feature_store.yaml)Please refer to the maintainers doc if you would like to locally test out the github actions workflow changes. This document will help you setup your fork to test the ci integration tests and other workflows without needing to make a pull request against feast-dev master.
Feast data storage contracts are documented in the following locations: