Changed Esti Data Lake Storage Gen2 to use a mock for CosmosDB#10173
Changed Esti Data Lake Storage Gen2 to use a mock for CosmosDB#10173
Conversation
This reverts commit 3e05e4f.
| - LAKEFS_DATABASE_COSMOSDB_ENDPOINT=http://127.0.0.1:8081 | ||
| - LAKEFS_DATABASE_COSMOSDB_DATABASE=esti-db | ||
| - LAKEFS_DATABASE_COSMOSDB_CONTAINER=esti-container | ||
| - LAKEFS_DATABASE_COSMOSDB_KEY=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw== |
There was a problem hiding this comment.
Is it cool to have it hard coded like that?
There was a problem hiding this comment.
Yes, it's only a mock DB random key 🙂
There was a problem hiding this comment.
Maybe adding something like FAKE_KEY_ to avoid security auditing from suspecting this as real key leak?
| mkdir -p dist | ||
| go build -ldflags "-X github.com/treeverse/lakefs/pkg/version.Version=${VERSION}" -o dist/lakefs ./cmd/lakefs | ||
| go build -ldflags "-X github.com/treeverse/lakefs/pkg/version.Version=${VERSION}" -o dist/lakectl ./cmd/lakectl |
There was a problem hiding this comment.
Could these binaries be kept at the root? If so, can this be replaced with:
make build-binaries VERSION=${{ needs.gen-code.outputs.tag }}
If not, does it make sense to add support for BINARIES_DIR (or something similar) to build-binaries target in the Makefile and use that here?
Isan-Rivkin
left a comment
There was a problem hiding this comment.
I vote against using a mock, we don't have anything to test cosmosdb.
mock of cosmos that is not even maintained by azure doesn't give us any confidence.
speed is secondary goal.
@N-o-Z As far as I remember, we used to test things with mock, right? |
@Isan-Rivkin Can you please review the build and push image step? |
We use mocks for unit tests not for integration tests. For dynamoDB we use a local implementation but that is an AWS official and maintained image |
Two changes to speed up Esti's run: