Pedantic I know, but add OS and personal choice tool-specific stuff like IDE cruft to your global gitignore, so you don't have to mess with it for every project: see git help gitignore, but TL;DR it's ~/.config/git/ignore

I don't think we want to include changes to Helm config now, right?

Maybe this PR is just for sharing between us for the moment, that's fine. I don't know if the upstream project would want a docker-compose.yml contributed to the project or not since they'd probably encourage people to use Kubernetes + Helm locally instead, but if we do end up going with Feast then keeping it on our internal fork makes sense to me, for development convenience.

When you say keeping this, did you mean the docker-compose.yml file, or the change in values.yml file? I'm a little confused by the conclusion whether I should keep this or remove?
Or should I move this change to a different PR?

Sorry, by "keeping it" I did mean the Docker Compose file. I think that should be on the "Agoda master" branch that we presumably maintain going forward (though I agree with what you mentioned in chat, we should make it build from the Dockerfiles in the repo instead of referencing the gcr.io registry images—build: path/to/Dockerfile).

If we're not going to be using Kubernetes for the time being then I think we shouldn't merge any changes to the Helm configuration, it's just going to be potential conflict churn to work around when syncing up with upstream updates.

You can remove this line, then update these below:

STORE_SERVING_OPTIONS: '{"host": "redis", "port": "6379"}'
FEAST_CORE_HOST: core

With Docker Compose the service names are resolvable hostnames by default, not just the generated container names, so this avoids the URISyntaxException problem you were having with feast_core_1 as a URL.