如何使用Gitlab CI来构建Java Maven项目？

注册一个 Docker 运行器并使用一个官方的 Maven Docker 镜像，例如，在您的文件中：maven:3-jdk-11.gitlab-ci.yml

image: maven:3-jdk-11

build:
  script: "mvn install -B"

请注意该标志，建议将其用于非交互式使用。-B

据我所知，跑步者是共享的还是特定的并不重要。

这里有几个问题。

我将开始回答Java构建问题，然后是Runners问题。

Java 构建

我将从最基本的 Java 构建配置开始，逐步添加功能。

1. 基本的Java构建

此配置有望运行 Maven 生成（并且仅运行生成，显式排除单元测试）：

stages:
  - build

java-build:
  # select the most appropriate image for your project
  image: maven:3.8-openjdk-11
  stage: build
  script:
    - mvn package -DskipTests=true

2.具有伪影，缓存和推荐的Maven选项

这个新版本：

• 将 Maven 构建输出声明为 GitLab 工件（供以后在下游管道中使用），
• 利用 GitLab 的缓存来缓存本地 Maven 存储库（在 中），.m2/repository
• 还强制执行一些建议的 Maven 选项，以便在 CI/CD 上下文中使用。

stages:
  - build

variables:
  # This will suppress any download for dependencies and plugins or upload messages which would clutter the console log.
  # `showDateTime` will show the passed time in milliseconds. You need to specify `--batch-mode` to make this work.
  MAVEN_OPTS: >-
    -Dhttps.protocols=TLSv1.2
    -Dmaven.repo.local=.m2/repository
    -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
    -Dorg.slf4j.simpleLogger.showDateTime=true
    -Djava.awt.headless=true
  # As of Maven 3.3.0 instead of this you may define these options in `.mvn/maven.config` so the same config is used
  # when running from the command line.
  # `installAtEnd` and `deployAtEnd` are only effective with recent version of the corresponding plugins.
  MAVEN_CLI_OPTS: >-
    --batch-mode
    --errors
    --fail-at-end
    --show-version
    -DinstallAtEnd=true
    -DdeployAtEnd=true  

java-build:
  # select the most appropriate image for your project
  image: maven:3.8-openjdk-11
  stage: build
  # Cache downloaded dependencies and plugins between builds.
  # The key here separates one cache per branch/tag ($CI_COMMIT_REF_SLUG)
  cache:
    key: "maven-$CI_COMMIT_REF_SLUG"
    paths:
      - .m2/repository
  script:
    - mvn $MAVEN_CLI_OPTS package -DskipTests=true
  artifacts:
    name: "Maven artifacts from $CI_PROJECT_NAME on $CI_COMMIT_REF_SLUG"
    paths:
      - "**/target"

3. 使用单元测试

在 CI/CD 管道中集成单元测试时，有两个选项：

1. 在与生成相同的作业中运行它们
2. 在单独的作业中运行它们

作为管道执行速度和绿色IT考虑因素的问题，我绝对更喜欢选项1，但我承认人们可能更喜欢第二个选项。

下面是该文件的新版本，还实现了 GitLab 单元测试集成：.gitlab-ci.yml

stages:
  - build

variables:
  # This will suppress any download for dependencies and plugins or upload messages which would clutter the console log.
  # `showDateTime` will show the passed time in milliseconds. You need to specify `--batch-mode` to make this work.
  MAVEN_OPTS: >-
    -Dhttps.protocols=TLSv1.2
    -Dmaven.repo.local=.m2/repository
    -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
    -Dorg.slf4j.simpleLogger.showDateTime=true
    -Djava.awt.headless=true
  # As of Maven 3.3.0 instead of this you may define these options in `.mvn/maven.config` so the same config is used
  # when running from the command line.
  # `installAtEnd` and `deployAtEnd` are only effective with recent version of the corresponding plugins.
  MAVEN_CLI_OPTS: >-
    --batch-mode
    --errors
    --fail-at-end
    --show-version
    -DinstallAtEnd=true
    -DdeployAtEnd=true  

java-build-and-test:
  # select the most appropriate image for your project
  image: maven:3.8-openjdk-11
  stage: build
  # Cache downloaded dependencies and plugins between builds.
  # The key here separates one cache per branch/tag ($CI_COMMIT_REF_SLUG)
  cache:
    key: "maven-$CI_COMMIT_REF_SLUG"
    paths:
      - .m2/repository
  script:
    # the 'verify' goal is definitely the most appropriate here
    - mvn $MAVEN_CLI_OPTS verify
  artifacts:
    name: "Maven artifacts from $CI_PROJECT_NAME on $CI_COMMIT_REF_SLUG"
    paths:
      - "**/target"
    reports:
      # declare the JUnit reports (recursive pattern for multi-module projects)
      junit:
        - "**/target/*-reports/TEST-*.xml"

4. 走得更远

从此步骤开始，构建作业仍然可以进一步增强，例如代码覆盖率计算和集成，但这需要更多的代码。

另一种以更少的工作量实现最先进的管道的方法是使用GitLab CI / CD模板。例如：

• GitLab 的 Maven 模板
• 或待连续模板

连续是一个开源项目，它提供了一组即用型、可配置、可扩展、可组合的模板。

关于跑步者

GitLab架构非常通用，具有Runners的概念。运行器是基本的执行器池，可以执行 GitLab CI/CD 作业。

关于跑步者的2件有趣的事情

1.您可以专门化您的跑步者

使用 GitLab，您可以注册几种用于特殊和互补目的的跑步者。

为了隔离它们，GitLab支持标签的概念。在注册跑步者时，您应将其与功能标签名称相关联，这将有助于开发人员在其文件中选择最合适的标签名称。.gitlab-ci.yml

例如，假设您有 4 个跑步者：

通过此设置，同时具有 Java 和 .NET 代码的单存储库项目可以声明以下文件：.gitlab-ci.yml

stages:
  - build
  - test
  - deploy

# this job declares no tag: will be executed by default runner (#1)
java-build:
  image: maven:3.8-openjdk-11
  stage: build
  script:
    - Java build code here

dotnet-build:
  image: mcr.microsoft.com/dotnet/sdk:5.0
  stage: build
  tags:
    - windows
    - general
  script:
    - .NET build code here

# this job declares no tag: will be executed by default runner (#1)
java-test:
  image: maven:3.8-openjdk-11
  stage: test
  script:
    - Java test code here

dotnet-test:
  image: mcr.microsoft.com/dotnet/sdk:5.0
  stage: test
  tags:
    - windows
    - general
  script:
    - .NET test code here

deploy:
  stage: deploy
  tags:
    - deploy
    - datacenter
  script:
    - deployment code here

2.跑步者有不同的范围

引用官方文档：

跑步者可根据您希望访问的人员提供：

• 共享运行器可用于 GitLab 实例中的所有组和项目。
• 组运行器可用于组中的所有项目和子组。
• 特定的运行者与特定的项目相关联。通常，特定的运行器一次用于一个项目。