I'm playing with helm files my colleague April made for our demo deployment, trying to make them more generalizable.
One thing I noticed was that spinning up the Solr with the right config was a separate step, so I thought it would be nice to build a docker image that's just the Solr image with the config that matches the release you're working with.
Here's a link to the Dockerfile and the github action to publish it - is this something that would be valuable to contribute back? If so, where would be the most appropriate place for it?
I don't think the rest of the helm chart stuff is ready to be folded in, but I could see the Solr image being handy.
I have had that same thought before and created such an image back when I started https://github.com/gdcc/dataverse-kubernetes
I stopped doing that and favored the more vanilla approach due to the at time available options with bitname/solr and apache/solr images.
But now that this is history and we probably won't look into using SolrCloud anytime soon, maybe it's worth using our custom derivate of the upstream Solr image again.
At some point we will probably also have to create a Keycloak image which gives us the special Dataverse module as a builtin.
When I was able to finally move on from gdcc/dataverse-kubernetes, I was really glad to finally be able to quickly build and use the images for development
Which is why the whole build pipeline is now centered in the upstream repo
If we can figure out a way to move the whole container business away from it without loosing this flexibility, I'm all ears.
I did play around with a few things lately to create custom pipelines with Maven. Maybe some of that would help. Or finally releasing the dataverse-parent module to Maven Central.
Hm, I think I need to learn more about the current build steps / dev steps - sounds like it's not helpful to contribute upstream at this point.
Not to shoot you down - I'm just saying maybe you asking about this is the right moment to talk about moving these things, so we make upstream a bit more lightweight again.
Thanks - I think I'm not clear on where the upstream things you're talking about vs. the downstream things are.
In IQSS/dataverse we have a Docker Maven Plugin centered build pipeline for the images. This allows anyone with Docker and the usual Java setup and almost no knowledge about Docker / Compose / ... to use containers for backend development with a single Maven command (and most of our devs are accustomed to using Maven CLI)
In addition, we're using Github Actions. These not only do the heavy lifting around Maven tests, but also run the build pipelines for containers
Container images are build and created for feature branches and PRs and pushed to ghcr.io. This way, backend and frontend devs can work together fast even without any knowledge about containers on the backend "end" (which is still somewhat true, as most devs at IQSS are still favoring a classic setup)
Images are also built and pushed from these pipelines at release time or as snapshots of the develop branch when a PR is merged
These go to Docker Hub, ready to be used by the community, sysadmins, devs, integrators, etc
And finally, we have a pipeline that automates maintenance of the said images.
For the past 3 releases we maintain the images to receive security updates and push these to Docker Hub, following the Bitnami naming pattern.
We can't take away the containerized build of images in the development pipelines, as they are getting more and more important to run integration and API tests for code changes in the main codebase.
Does that give a better comprehension about the ecosystem?
I'm not entirely sure if we'd be able to move on from using Maven to fire up containers to a more "pure" compose style setup. Before we think in that direction, let's make sure to talk to devs that now are using containers how they'd feel about that. Again - not for building images, but for running them. It's far to important to have proper access to Maven properties and tie in with the overall webapp build process, which is really hard impossible in pure Compose.
Last updated: May 30 2026 at 09:11 UTC