blaze icon indicating copy to clipboard operation
blaze copied to clipboard

Releases: add missing artifacts

Open allentiak opened this issue 1 year ago • 1 comments

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:

  • A link to the corresponding Docker image from https://hub.docker.com/r/samply/blaze
  • The Uberjar itself.

allentiak avatar Sep 10 '24 13:09 allentiak

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

alexanderkiel avatar Sep 12 '24 07:09 alexanderkiel

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?

Jolly5 avatar Nov 19 '24 15:11 Jolly5

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.

alexanderkiel avatar Nov 19 '24 17:11 alexanderkiel

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 :)

Jolly5 avatar Nov 20 '24 16:11 Jolly5

Closed due to lag of current interest.

alexanderkiel avatar Aug 21 '25 06:08 alexanderkiel