利用自定义停靠映像会导致生成管道失败。

Question

我正试图为我在空闲时间做的一个小项目创建一个构建管道。为此，我利用弹簧-启动和角.在本地，我使用./gradlew clean build构建它。这在我的本地机器上运行得很好，但是我遇到了一些我无法在gitlab上找到的问题。构建是在gitlab上完成的，使用它自己的共享运行程序。

我的.gitlab-ci.yml看起来是这样的：

    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

在上面的例子中，我使用了一个基于openjdk:17-jdk-bullseye的坞映像，但是扩展到npm可用。对应的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"]

我试图使用生成的对接容器构建我的项目，方法是将我的代码作为卷添加，然后运行./gradlew build --它在我的机器上工作。我的假设是，通过这一点，我基本上模拟了gitlab-runner在开始构建时的行为。

    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

这是构建管道的输出：

   $ 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

现在，我做了以下观察

当我的构建作为intended.

• Whenever使用openjdk:17-jdk-bullseye映像时，我使用的是openjdk:17-jdk-bullseye，在输出中看不到这一行：

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

我知道我是根用户，所以我应该能够在.../bin/gradle

• When上设置+x，在我的项目中运行ll，这就是我在gradlew上看到的：-rwxr-xr-x 1 alex staff [ ... ] gradlew

不幸的是，我没有任何想法，我会感谢任何后续问题或观察，我已经失去了。对于这个问题，最常见的答案似乎是“确保gradlew是可执行的！”--没错。

在输入这个答案时，我想知道这是否是一个与x86/x64/arm64相关的问题？我刚刚注意到在码头枢纽上OS/ARCH字段设置为linux/arm64/v8。

Answer 1

正如sytech所建议的--我刚刚用gitlab构建并推进了这个对接映像，并将其推入容器存储库。然后，我在我的应用程序构建中使用了它--它可以像预期的那样工作。

.gitlab-ci.yml存储库中的Dockerfile如下所示：

  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

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

然后，它将构建发布到我的存储库的容器存档中。

在另一个构建中，我简单地引用了构建：

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

启动一个新的构建-然后构建最终工作：

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

我怀疑建筑是罪魁祸首。