CODEWITHSUNDEEP
dockergitlabgitlab-ci
almac777
almac777

Reputation: 569

Utilizing custom docker-image causes build pipeline failure

I am trying to create a build pipeline for a small project I do on my free time. For this, I utilize Spring-Boot and Angular. Locally I build it with ./gradlew clean build. This works perfectly fine on my local machine, but I run into issues I can't pinpoint on gitlab. The build is done on gitlab, utilizing it's own shared runners.

My .gitlab-ci.yml looks like this:

    default:
      image: oasisat777/openjdk-and-node:latest

    # If I comment out above line and comment in the line below, everything works fine & dandy
    # image: openjdk:17-jdk-bullseye

    stages:
       - build

    build-job:
       stage: build
       script:
         - whoami
         - java -version
         - npm -v
         - ./gradlew clean compileTestJava compileJava --stacktrace

In the above example I use a docker image based on openjdk:17-jdk-bullseye but extended to have npm available. The corresponding Dockerfile:

    # goal: build microservices with spring-boot backend and angular frontend in gitlab
    # req'd images: latest stable openjdk and latest node
    # unfortunately there's not openjdk-with-node:latest available, so i have to build it by hand
    # this ought to do the trick, using bullseye as base and then install node additionally
    FROM openjdk:17-jdk-bullseye

    # note: for production use node LTS (even numbers)
    # https://github.com/nodesource/distributions/blob/master/README.md#deb
    RUN curl -fsSL https://deb.nodesource.com/setup_17.x | bash - \
        && apt-get install -y nodejs

    USER root

    CMD ["bash"]

I tried to build my project utilizing the resulting docking container by adding my code as a volume then run ./gradlew build - which worked on my machine. My assumption is that by this I basically simulated the behavior of what the gitlab-runner does when starting the build.

    docker run -it -v .:/project
    cd project
    ./gradlew clean build
    Downloading https://services.gradle.org/distributions/gradle-7.4.1-bin.zip
...........10%...........20%...........30%...........40%...........50%...........60%...........70%...........80%...........90%...........100%
    Welcome to Gradle 7.4.1!
    Here are the highlights of this release:
     - Aggregated test and JaCoCo reports
     - Marking additional test source directories as tests in IntelliJ
     - Support for Adoptium JDKs in Java toolchains
    For more details see https://docs.gradle.org/7.4.1/release-notes.html
    Starting a Gradle Daemon (subsequent builds will be faster)
    [...]
    BUILD SUCCESSFUL

This is the output of the build-pipeline:

   $ whoami
   root
   $ java -version
   openjdk version "17.0.2" 2022-01-18
   OpenJDK Runtime Environment (build 17.0.2+8-86)
   OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
   $ npm -v
   8.5.5
   $ ./gradlew clean compileTestJava compileJava --stacktrace
   Downloading https://services.gradle.org/distributions/gradle-7.4.1-bin.zip
...........10%...........20%...........30%...........40%...........50%...........60%...........70%...........80%...........90%...........100%
   Could not set executable permissions for: /root/.gradle/wrapper/dists/gradle-7.4.1-bin/58kw26xllvsiedyf3nujyarhn/gradle-7.4.1/bin/gradle
   Welcome to Gradle 7.4.1!
   Here are the highlights of this release:
     - Aggregated test and JaCoCo reports
     - Marking additional test source directories as tests in IntelliJ
     - Support for Adoptium JDKs in Java toolchains
    For more details see https://docs.gradle.org/7.4.1/release-notes.html
    Starting a Gradle Daemon (subsequent builds will be faster)
    FAILURE: Build failed with an exception.
    * What went wrong:
    A problem occurred starting process 'Gradle build daemon'
    * Try:
    > Run with --info or --debug option to get more log output.
    > Run with --scan to get full insights.
    * Exception is:
    org.gradle.process.internal.ExecException: A problem occurred starting process 'Gradle build daemon'
    at org.gradle.process.internal.DefaultExecHandle.execExceptionFor(DefaultExecHandle.java:241)
    at org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:218)
    at org.gradle.process.internal.DefaultExecHandle.failed(DefaultExecHandle.java:369)
    at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:87)
    at org.gradle.internal.operations.CurrentBuildOperationPreservingRunnable.run(CurrentBuildOperationPreservingRunnable.java:38)
    at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
    at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:833)
    Caused by: net.rubygrapefruit.platform.NativeException: Could not start '/usr/local/openjdk-17/bin/java'
    at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:27)
    at net.rubygrapefruit.platform.internal.WrapperProcessLauncher.start(WrapperProcessLauncher.java:36)
    at org.gradle.process.internal.ExecHandleRunner.startProcess(ExecHandleRunner.java:98)
    at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:71)
    ... 6 more
    Caused by: java.io.IOException: Cannot run program "/usr/local/openjdk-17/bin/java" (in directory "/root/.gradle/daemon/7.4.1"): error=0, Failed to exec spawn helper: pid: 106, exit value: 1
    at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
    at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
    at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
    ... 9 more
    Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 106, exit value: 1
    at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
    at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
    at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
    at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
    ... 11 more
   * Get more help at https://help.gradle.org
   Cleaning up project directory and file based variables

Now, I made the following observations

Could not set executable permissions for: /root/.gradle/wrapper/dists/gradle-7.4.1-bin/58kw26xllvsiedyf3nujyarhn/gradle-7.4.1/bin/gradle

Unfortunately I ran out of ideas and would be thankful for any follow up questions or observations that I have lost. The most common answer to this problem seems to be "Make sure that gradlew is executable!" - well it is.

While typing this answer, I was wondering whether this could be an x86/x64/arm64 related issue? I just noticed the OS/ARCH field is set to linux/arm64/v8 on docker hub.

Upvotes: 3

Views: 1070

Answers (1)

almac777
almac777

Reputation: 569

It worked as sytech suggested - I've just built & pushed the docker-image using gitlab and pushed it into its container repository. I then used it in my application build - and it works as expected.

The .gitlab-ci.yml in the Dockerfile repository looks like this:

  variables:
    IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
    # Tell 'docker:dind' to enable TLS (recommended)
    # and generate certificates in the specified directory.
    DOCKER_TLS_CERTDIR: "/certs"
  
  build-push-docker-image-job:
    # Specify a Docker image to run the job in.
    image: docker:latest
    # Specify an additional image 'docker:dind' ("Docker-in-Docker") that
    # will start up the Docker daemon when it is brought up by a runner.
    services:
      - docker:dind
    script:
      - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
      - docker build -t $IMAGE_TAG .
      - docker push $IMAGE_TAG
    only:
      - master

(=> source: https://www.shellhacks.com/gitlab-ci-cd-build-docker-image-push-to-registry)

This then publishes the build into my repository's container archive.

In the other build I simply reference the build:

default:
  image: registry.gitlab.com/<GROUP>/<PROJECT>/<SOME_NAME>:master

start a new build - and then the build finally works:

BUILD SUCCESSFUL in 3m 7s
11 actionable tasks: 8 executed, 3 up-to-date
Cleaning up project directory and file based variables
00:00
Job succeeded

I suspect the architecture to be the culprit.

Upvotes: 2

Related Questions