You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, thanks for your efforts here, they are really appreciated. I used to maintain these sorts of things years ago, it has always been a huge gap in the whole community that these things didn't exist.
A lot of builds use sbt-docker to spin up integration tests, or sbt-native-packager to produce docker outputs. I would go so far as to say that it's standard practice nowadays to do this for anything except a published library jar.
Would you be open to adding the docker binary (and possibly even docker-compose, although that is perhaps more niche) to your base images to accommodate that very common usecase?
It's no big thing if you say no, your images already provide a great base for teams to add their build deps onto.
The text was updated successfully, but these errors were encountered:
I don't believe there would be any additional requirement for people using it as-is. Privileged mode or passing a socket through would only be necessary when spawning a new container.
Hi, thanks for your efforts here, they are really appreciated. I used to maintain these sorts of things years ago, it has always been a huge gap in the whole community that these things didn't exist.
A lot of builds use
sbt-docker
to spin up integration tests, orsbt-native-packager
to produce docker outputs. I would go so far as to say that it's standard practice nowadays to do this for anything except a published library jar.Would you be open to adding the
docker
binary (and possibly evendocker-compose
, although that is perhaps more niche) to your base images to accommodate that very common usecase?It's no big thing if you say no, your images already provide a great base for teams to add their build deps onto.
The text was updated successfully, but these errors were encountered: