Why include Scala?

[charpov]

I've been maintaining my own java+sbt image for a few years, but I'd rather switch to yours to make my life simpler. I'm wondering why you include Scala in the image, given that sbt is all you need to run a project. Also, since sbt can download specific versions of itself, why specify a version at all? If all that was specified is the Java version, it would greatly simplify the tags. For instance, right now, there's no image for the latest LTS Java (17) latest sbt (1.9.0) and latest Scala (3.3.0). (Actually, there is; makes my point about having too many tags...)

[francisdb]

We try to bootstrap sbt for a certain scala version so that it is ready for use and does not require any further downloads.

I do agree that the separate scala we install is a bit overkill if you only want sbt as sbt will pull in scala in a different folder on bootstrap. Initially the idea was to have an image that could also be used for scala without using sbt. (before the repo was moved over here)

docker-sbt/eclipse-temurin/Dockerfile

Lines 62 to 71 in 91d72cf

	# Prepare sbt (warm cache)
	RUN \
	sbt sbtVersion && \
	mkdir -p project && \
	echo "scalaVersion := \"${SCALA_VERSION}\"" > build.sbt && \
	echo "sbt.version=${SBT_VERSION}" > project/build.properties && \
	echo "// force sbt compiler-bridge download" > project/Dependencies.scala && \
	echo "case object Temp" > Temp.scala && \
	sbt compile && \
	rm -r project && rm build.sbt && rm Temp.scala && rm -r target

Personally I would not mind removing the separate scala install but that will not change anything regarding labeling of sbt-scala image as we still want to bootstrap the sbt/scala combo.

[charpov]

Understood. I used to do that too (bootstrapping) but I eventually gave up. With good caching/volumes, I don't mind having everything downloaded one time. Smaller image with less frequent updates too.
I guess a plain eclipse-temurin-17 tag (with sbt and Scala set to whatever) would make my life easier, but I can manage without it.

[blandflakes]

Wanted to check in on this issue - our team has many builds, and we are considering moving from our homegrown docker container to something more official that we're certain does things correctly.

However, these images present a challenge for a team that frequently updates libraries using a tool such as scala-steward. We have to update the image tag any time there's a new sbt version or scala version, which basically guarantees that we're constantly building with the "wrong" image.

How are others using these images in environments like this? Are there more generic "official" images that I just haven't found yet?

[charpov]

I would still much prefer a tag that is based solely on the Java version. The image can use any (recent) sbt and any Scala (or even no Scala at all). I'm setting up which sbt and which Scala I want in my project anyway. I would then use "latest Java 21" and be done with that.

[rparree]

@blandflakes it is indeed a nuisance. Every time Renovate or Scala Steward has a MR, i need to figure out what image is available for that particular Scala version with that specific Java version, then make sure the sbt file is in synch with the build container.
How are people are indeed using this image?

For reference, here's our variables in a gitlab pipeline

variables:
  ECLIPSE_TEMURIN_VERSION: "23.0.1_11"
  JDK_VERSION: eclipse-temurin-${ECLIPSE_TEMURIN_VERSION}
  SBT_VERSION: 1.10.6
  SCALA_VERSION: 3.6.4
  SBT_CREDENTIALS: /root/.sbt/.credentials
  JRE_IMAGE: eclipse-temurin:${ECLIPSE_TEMURIN_VERSION}-jre-alpine
  BUILD_IMAGE: repo.k8s.edc4it.com/sbtscala/scala-sbt:${JDK_VERSION}_${SBT_VERSION}_${SCALA_VERSION}

Below is a script i have been using

verify.sh

#!/bin/bash

# Define the build file and Nexus proxy
BUILD_FILE=".gitlab-ci.yml"
NEXUS_PROXY=""

# Extract variables using yq and expand environment variables
ECLIPSE_TEMURIN_VERSION=$(eval echo $(yq eval '.variables.ECLIPSE_TEMURIN_VERSION' "$BUILD_FILE"))
JDK_VERSION=$(eval echo $(yq eval '.variables.JDK_VERSION' "$BUILD_FILE"))
SBT_VERSION=$(eval echo $(yq eval '.variables.SBT_VERSION' "$BUILD_FILE"))
SCALA_VERSION=$(eval echo $(yq eval '.variables.SCALA_VERSION' "$BUILD_FILE"))
JRE_IMAGE=$(eval echo $(yq eval '.variables.JRE_IMAGE' "$BUILD_FILE"))
BUILD_IMAGE=$(eval echo $(yq eval '.variables.BUILD_IMAGE' "$BUILD_FILE"))

# Strip the local Nexus repository prefix from BUILD_IMAGE
BUILD_IMAGE_DOCKER_HUB=$(echo "$BUILD_IMAGE" | sed "s|$NEXUS_PROXY/||")

# Function to check if a Docker image exists on Docker Hub
check_image_exists() {
    local image=$1
    local repo=$(echo "$image" | cut -d':' -f1)
    local tag=$(echo "$image" | cut -d':' -f2)

    if [ -z "$tag" ]; then
        tag="latest"
    fi

    # Prepend 'library/' if the repository name does not contain a slash
    if [[ "$repo" != */* ]]; then
        repo="library/$repo"
    fi

    # Search for the repository
    local search_url="https://hub.docker.com/v2/repositories/$repo/"
    local search_response=$(curl -s -o /dev/null -w "%{http_code}" "$search_url")

    if [ "$search_response" -ne 200 ]; then
        echo "Repository does not exist on Docker Hub: $repo"
        echo "Response code: $search_response"
        return
    fi

    # Check if the specific tag exists
    local tag_url="https://hub.docker.com/v2/repositories/$repo/tags/$tag/"
    local tag_response=$(curl -s -w "%{http_code}" -o response.txt "$tag_url")

    if [ "$tag_response" -eq 200 ]; then
        echo "Image exists on Docker Hub: $image"
    else
        echo "Image does not exist on Docker Hub: $image (tag $tag)"
        echo "Response code: $tag_response"
        echo "Response text: $(cat response.txt)"
    fi

    # Clean up
    rm -f response.txt
}

# Check if JRE_IMAGE exists
check_image_exists "$JRE_IMAGE"

# Check if BUILD_IMAGE exists on Docker Hub
check_image_exists "$BUILD_IMAGE_DOCKER_HUB"

[francisdb]

We could create a second image without the separate scala. But you would still have the same 3 versions to select as they are needed for the jvm, sbt and the sbt scala cache warmup.

[charpov]

How about a light version, without the sbt cache? Could that be based on the Java version only? Back when I was maintaining my own image, I eventually stopped bothering with filling up the sbt cache after I realized they are enough opportunities for caching elsewhere.

[eed3si9n]

Also, since sbt can download specific versions of itself, why specify a version at all?

When we talk about sbt, it could mean sbt-the-bash-script (aka runner), sbt-the-main-artifact (aka server), or sbt-the-content-of-whatever-installer-installs, which is actually the combination of sbt-the-bash-script, launcher, and sbtn.
See also https://www.scala-sbt.org/2.x/docs/en/guide/sbt-components.html

1. I think the main benefit of having a Docker container would be getting the latest sbt-the-bash-script, and
2. the secondary benefit is that you get sbt-the-main-artifact preloaded into Coursier cache

[francisdb]

I'm not sure it makes a lot of sense to just provide sbt-the-bash-script on top of jvm images. It's a single line curl / wget to https://raw.githubusercontent.com/sbt/sbt/refs/tags/v1.10.11/sbt ? This can easily be added to your own docker image build.

[charpov]

But that means I'd have to go back maintaining my own build! 😏
If I'm the only one with this need, so be it, but if there are more of us, having the image here would avoid duplicating these builds.