5

Here is my configuration which worked for more than one year but suddenly stopped working.

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""


  stage: deploy
  image: "hseeberger/scala-sbt:11.0.9.1_1.4.4_2.13.4"
  before_script:
    - apt-get update
    - apt-get install sudo
    - apt-get install apt-transport-https ca-certificates curl software-properties-common -y
    - curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
    - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
    - apt-get update
    - apt-get install docker-ce -y
    - sudo service docker start
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

  script:
    - sbt docker:publishLocal

The error in GitlabCI is the following:

[warn] [1] sbt-native-packager wasn't able to identify the docker version. Some features may not be enabled
[warn] sbt-native packager tries to parse the `docker version` output. This can fail if
[warn] 
[warn]   - the output has changed:
[warn]     $ docker version --format '{{.Server.APIVersion}}'
[warn] 
[warn]   - no `docker` executable is available
[warn]     $ which docker
[warn] 
[warn]   - you have not the required privileges to run `docker`
[warn] 
[warn] You can display the parsed docker version in the sbt console with:
[warn] 
[warn]   sbt:your-project> show dockerApiVersion
[warn] 
[warn] As a last resort you could hard code the docker version, but it's not recommended!!
[warn] 
[warn]   import com.typesafe.sbt.packager.docker.DockerApiVersion
[warn]   dockerApiVersion := Some(DockerApiVersion(1, 40))
[warn]           
[success] All package validations passed
[error] Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
[info] Removing intermediate image(s) (labeled "snp-multi-stage-id=9da90b0c-75e0-4f46-98eb-a17a1998a3b8") 
[error] Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
[error] Something went wrong while removing multi-stage intermediate image(s)
[error] java.lang.RuntimeException: Nonzero exit value: 1
[error]     at com.typesafe.sbt.packager.docker.DockerPlugin$.publishLocalDocker(DockerPlugin.scala:687)
[error]     at com.typesafe.sbt.packager.docker.DockerPlugin$.$anonfun$projectSettings$41(DockerPlugin.scala:266)
[error]     at com.typesafe.sbt.packager.docker.DockerPlugin$.$anonfun$projectSettings$41$adapted(DockerPlugin.scala:258)
[error]     at scala.Function1.$anonfun$compose$1(Function1.scala:49)
[error]     at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:62)
[error]     at sbt.std.Transform$$anon$4.work(Transform.scala:68)
[error]     at sbt.Execute.$anonfun$submit$2(Execute.scala:282)
[error]     at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:23)
[error]     at sbt.Execute.work(Execute.scala:291)
[error]     at sbt.Execute.$anonfun$submit$1(Execute.scala:282)
[error]     at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:265)
[error]     at sbt.CompletionService$$anon$2.call(CompletionService.scala:64)
[error]     at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error]     at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[error]     at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error]     at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[error]     at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[error]     at java.base/java.lang.Thread.run(Thread.java:834)
[error] (Docker / publishLocal) Nonzero exit value: 1
ofirule
  • 4,233
  • 2
  • 26
  • 40
Ducaz035
  • 3,054
  • 2
  • 25
  • 45
  • What version of `sbt-native-packager` is declared in your `project/plugins.sbt`? We had an issue a few months ago where upgrading the docker daemon (not sure of the exact version, sorry) didn't play well with `sbt-native-packager:1.5.0`. Upgrading to `1.8.0` or higher fixed the issue, but I can't tell if you're experiencing the same bug. – MSmedberg Aug 13 '21 at 16:33
  • I have 1.5.0 by default but tried with the latest version which didn't help either. Did you do anything special except adding it to the plugins.sbt? – Ducaz035 Aug 14 '21 at 21:46
  • Something ought to have changed in your GitlabCI environment? It clearly cannot connect to your docker daemon and get expected response from it. What has your investigation led to so far? Some of the things I would check is Is Docker daemon running? Has docker version changed/upgraded? Does the run-as user have required privileges to run docker? would sudo-ing help? Has the base image for your CI environment changed? – sparker Aug 15 '21 at 15:21
  • Base image is same, there is a recent docker version which may cause this but I couldn't figure out why. – Ducaz035 Sep 06 '21 at 22:24

2 Answers2

1

I finally solved it by installing Sbt instead of Docker. I also use Docker in Docker service from Gitlab now that basically helps me avoid the problem above.

image: docker:19.03.12

services:
  - mysql:latest
  - docker:19.03.12-dind

docker:image:
  needs: ["test"]
  stage: deploy
  before_script:
    - apk update
    - apk --no-cache add openjdk11
    - export PATH="/usr/local/sbt/bin:$PATH"
    - apk update && apk add bash ca-certificates wget tar && mkdir -p "/usr/local/sbt" && wget -qO - --no-check-certificate "https://github.com/sbt/sbt/releases/download/v1.5.5/sbt-1.5.5.tgz" | tar xz -C /usr/local/sbt --strip-components=1 && sbt sbtVersion
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - sbt docker:publishLocal
    - docker tag x:latest registry.gitlab.com/x/y:0.1-SNAPSHOT-$(date +%Y-%m-%d-%H-%M)
    - docker push registry.gitlab.com/x/y/project-$(date +%Y-%m-%d-%H-%M)
  only:
    - master
Ducaz035
  • 3,054
  • 2
  • 25
  • 45
0

It looks like you trying to run the docker daemon inside your build image docker run.

For Linux, you need to make sure that the current user (the one running sbt), has the proper permissions to run docker commands with some post-install steps.

Maybe you could fix your script by running sudo sbt docker:publishLocal instead?

It is more common now to use a service to have a docker daemon already set up for your builds:

services:
  - docker:dind

See this example on gitlab. There is also a section in the (EE) docs.

adrobisch
  • 316
  • 1
  • 3
  • How can I install Sbt and Scala on a Gitlab DID image? – Ducaz035 Sep 06 '21 at 22:23
  • FYI, the post-install steps didn't work for me in this scenario. `whoami` returns `root`, and even root couldn't run the docker commands. I think for a shared runner, dind might be the only way to go. – tunesmith Apr 23 '23 at 05:58