samply / blaze

A FHIR® Server with internal, fast CQL Evaluation Engine
https://samply.github.io/blaze
Apache License 2.0
157 stars 18 forks source link

Releases: add missing artifacts #2033

Open allentiak opened 2 months ago

allentiak commented 2 months ago

Currently, the only artifact for releases is the source code. Whereas this is certainly good for reproducibility purposes, it has no "every day" use case.

Ideally, it would be nice to add:

alexanderkiel commented 2 months ago

We can add a link to the Docker images, but not the Uberjar, because I don't linke people to run the Uberjar standalone.

Jolly5 commented 2 weeks ago

We can add a link to the Docker images, but not the Uberjar, because I don't linke people to run the Uberjar standalone.

If you don't like people to run the Uberjar, what is the preferred way of setting up a temporary test instance? E.g. for integration tests of ETL pipelines?

alexanderkiel commented 2 weeks ago

We can add a link to the Docker images, but not the Uberjar, because I don't linke people to run the Uberjar standalone.

If you don't like people to run the Uberjar, what is the preferred way of setting up a temporary test instance? E.g. for integration tests of ETL pipelines?

Docker is always the preferred way to run Blaze, because with Docker, the JVM and the Libs that RocksDB needs are controllable. Is there anything that prevents you to use Docker in such an integration test scenario? If you look into the GitHub Action pipeline of the Blaze repo itself, it starts several Docker containers for integration tests of Blaze itself. Also in software components that use Blaze, like FLARE and TORCH we run the Blaze container even in JUnit tests using the Testcontainers library.

Jolly5 commented 1 week ago

Docker is always the preferred way to run Blaze, because with Docker, the JVM and the Libs that RocksDB needs are controllable. Is there anything that prevents you to use Docker in such an integration test scenario? If you look into the GitHub Action pipeline of the Blaze repo itself, it starts several Docker containers for integration tests of Blaze itself. Also in software components that use Blaze, like FLARE and TORCH we run the Blaze container even in JUnit tests using the Testcontainers library.

Using docker containers for this purpose while keeping things flexible seemed difficult at me at first. But after looking it up I realized it's easier than I thought. Your comment still helps me and may help more people in the future, so thanks :)