Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ScalaCliDockerFile #2699

Closed
wants to merge 1 commit into from
Closed

Update ScalaCliDockerFile #2699

wants to merge 1 commit into from

Conversation

i10416
Copy link

@i10416 i10416 commented Jan 22, 2024

The stable tag is not clear about which debian version it uses.

docker run --rm -it --entrypoint cat  virtuslab/scala-cli:1.1.2 /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
docker run --rm -it --entrypoint cat  virtuslab/scala-cli:1.0.0-RC1 /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

@Gedochao
Copy link
Contributor

@i10416 Any reason why we'd want to lock the docker image at the bookworm-slim tag? (Debian 12)
I believe it's generally advised to use stable (stable-slim in our case).
If you need a particular debian version in your image, you can always add Scala CLI to it yourself, no?
I'd rather keep our image at stable-slim TBH...

@i10416 i10416 closed this Jan 23, 2024
@i10416
Copy link
Author

i10416 commented Jan 23, 2024

Thank you for feedback.

Any reason why we'd want to lock the docker image at the bookworm-slim tag

It is because the current latest image uses bookworm-slim.

If you mean "why I want to pin the base image to a specific version(regardless of current stable)", it is because I had trouble finding the reason why my application, which is a small http server written in Scala Native built in a Docker container based on virtuslab/scala-cli, couldn't find libcrypto.so at runtime(not build time as I added libssl-dev to the image) and it turned out that runtime does not contain a specific version of openssl or libssl-dev. The version of openssl is different between Debian version and I thought it is better to use absolute Debian version or name rather than relative one in terms of reproducibility.
Ididn't know that practice you linked above and no one but me complains about it, so I close this issue.

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants