Automate dependency upgrades for DB container images
Description
Activity
Yoann Rodière December 4, 2023 at 9:01 AM
This was addressed in https://github.com/hibernate/hibernate-search/pull/3796 as part of https://hibernate.atlassian.net/browse/HSEARCH-4674#icft=HSEARCH-4674
Yoann Rodière July 21, 2022 at 8:06 AM
Alternatively, we could switch to TestContainers and rely on the default version of the container image in TestContainers. That version should only be upgraded when we upgrade TestContainers, whose version would be managed by dependabot.
This would also have the advantage of speeding up the build, as there’s a way to have TestContainers start each container once for the whole build.
I’m not sure the default versions in TestContainers are appropriate, though… If they’re not, we’re back to square one.
Yoann Rodière July 21, 2022 at 8:00 AM
Since the version is currently contained in the root POM, it’s unlikely that Dependabot can handle this at the moment.
If we really want to use Dependabot, maybe we could create one Dockerfile per DB, with only a “FROM” line pointing to the image we want, and use that in the Maven-docker-plugin? Then dependabot would be able to upgrade the version in Dockerfiles.
There’s some challenge in adapting some of our code, though, such as the list-container-images goal in the root POM; maybe we convert that to listing dockerfiles instead? See how it’s used in the Jenkinsfile.
Currently we use Dependabot to automatically detect and upgrade Maven dependencies, but we don’t have anything for container images.
We don’t really need anything for Elasticsearch container images, as we track Elasticsearch releases manually and rather closely, but we do need something for DB container images.
It would be nice to have Dependabot send a PR every week/month to upgrade the version of DB container images.
Before someone suggests it, using the
latesttag is not an option as it would make the build even more non-reproducible than it currently is: when we build Hibernate Search 6.2 again two years from now (for maintenance), we want it to use the same DB versions it used when 6.2.0 was released, otherwise the build might just fail because of incompatible changes in DBs, and we’re not interested in those changes.