kotlin 构建对象_在gitlab中为kotlin创建自动构建管道

Over the past few months I’ve been learning a bit of Gradle and Kotlin for a new project at work.

在过去的几个月中，我一直在学习Gradle和Kotlin的新项目。

At work we use an internal code repository that doesn’t have any sort of continuous integration or automated build process, so it’s up to us to manually run tests on our local machines. Unfortunately, we often forget to do this, and bugs can slip by unnoticed.

在工作中，我们使用内部代码存储库，该存储库没有任何形式的持续集成或自动构建过程，因此，我们需要在本地计算机上手动运行测试。 不幸的是，我们经常忘记这样做，并且错误可能会被忽视。

When working on personal projects I try to learn from what we do at work (both the good and the bad) and I strive to always set up test automation. In most cases, this means using Gitlab pipelines to build and test every single commit. This article describes how I set that up for Kotlin.

在处理个人项目时，我尝试从我们的工作中学习(无论好事还是坏事)，并且我努力始终设置测试自动化。 在大多数情况下，这意味着使用Gitlab管道来构建和测试每个提交。 本文介绍了如何为Kotlin进行设置。

什么是Gitlab管道？ (What are Gitlab Pipelines?)

The idea behind Gitlab pipelines is straightforward: define a set of steps to build and test your code, store those steps in a file in your repository, use Docker containers to run the defined steps, and finally, report back the results. It’s a simple concept but it’s very powerful.

Gitlab管道背后的想法很简单：定义一组步骤来构建和测试代码，将这些步骤存储在存储库中的文件中，使用Docker容器运行定义的步骤，最后报告结果。 这是一个简单的概念，但功能非常强大。

The following screenshot shows a section of the massive build pipeline used to build and test Gitlab’s own codebase.

以下屏幕截图显示了用于构建和测试Gitlab自己的代码库的大规模构建管道的一部分。

Note: The Gitlab software is open-source and hosted on gitlab. Gitlab is quite literally building itself using these pipelines.

注意：Gitlab软件是开源的，并托管在 gitlab上 。 实际上，Gitlab使用这些管道来构建自己。

By looking at the pipeline, you can get an idea of all the things it is doing. Compiling all kinds of assets, running tests, generating coverage reports, and so on. There are hundreds of steps involved, spread across multiple stages. They’re all automated and they all run for every single commit.

通过查看管道，您可以了解它正在做的所有事情。 编译各种资产，运行测试，生成覆盖率报告等。 涉及数百个步骤，分布在多个阶段。 它们都是自动化的，并且每次运行都可以运行。

How can this help you?

这对您有什么帮助？

The flexibility of pipelines gives you endless possibilities. You can define what Docker container to use, what stages you want, what steps fit into each stage, and what commands to run for each stage. There are all sorts of things you can automate. For example:

管道的灵活性为您提供了无限的可能性。 您可以定义要使用的Docker容器，所需的阶段，适合每个阶段的步骤以及可以在每个阶段运行的命令。 您可以自动进行各种操作。 例如：

• Test your code.
  测试您的代码。
• Run static code analysis to find anti-patterns.
  运行静态代码分析以找到反模式。
• Run style checkers to find style errors.
  运行样式检查器以查找样式错误。
• Run vulnerability scans.
  运行漏洞扫描。
• Check for out-of-date dependencies.
  检查过时的依赖关系。
• Validate commit messages to ensure they follow a given standard.
  验证提交消息，以确保它们遵循给定的标准。
• Run different steps on different branches/tags (e.g. Run a special publication script only on the master branch).
  在不同的分支/标记上运行不同的步骤(例如，仅在master分支上运行特殊的发布脚本)。

• Build and host a static site (documentation).

  构建并托管一个静态站点( 文档 )。

• Run tests against multiple database engines to ensure compatibility.
  针对多个数据库引擎运行测试以确保兼容性。

There are many others. You can read the docs for inspiration or take a look at the examples page.

还有很多。 您可以阅读文档以获取灵感，也可以查看示例页面。

将其应用于Kotlin (Applying it to Kotlin)

Since starting to use Kotlin and Gradle at work I’ve started using it for some of my personal projects as well. Figuring out a pipeline I can use in Gitlab for my Kotlin code was high on my to-do list.

自从开始在工作中使用Kotlin和Gradle以来，我也开始在一些个人项目中使用它。 找出可以在Gitlab中用于Kotlin代码的管道在我的工作清单上很重要。

For the purposes of this article, I created a demo project to demonstrate the solution I came up with. You can find it here: Kotlin Build Pipeline

出于本文的目的，我创建了一个演示项目来演示我提出的解决方案。 您可以在这里找到它： Kotlin构建管道

At a high level, this is what it does.

从高层次上讲，这就是它的作用。

The first stage is to compile the code. This stage has a single step that uses Gradle to compile.

第一步是编译代码。 这个阶段只有一个使用Gradle进行编译的步骤。

The second stage is to test the code. I split this into two types:

第二阶段是测试代码。 我将其分为两种类型：

• Run Ktlint to find style errors — a failure here will be interpreted as a warning and the pipeline will proceed.

  运行Ktlint来查找样式错误-此处的失败将被解释为警告，并且管道将继续进行。

• Run all the unit tests defined in the project — a failure here means the pipeline fails.
  运行项目中定义的所有单元测试-此处的失败表示管道失败。

Finally, build a “fat jar” file with all the dependencies to be published.

最后，构建一个带有所有要发布依赖项的“胖子”文件。

To set this up, I just need to create the .gitlab-ci.yml file in the root of the repository with the right instructions. Gitlab handles the rest.

要进行此设置，我只需要使用正确的说明在存储库的根目录中创建.gitlab-ci.yml文件。 Gitlab处理其余的工作。

So what is this file actually doing?

那么这个文件到底在做什么呢？

• image: The first line is to define which Docker container to use. In this case, I’m using a container with Java JDK 11 installed. The demo application is being built to target Java version 11 but this can be tweaked to target a different version of Java.

  image ：第一行是定义要使用的Docker容器。 在这种情况下，我使用的是装有Java JDK 11的容器。 该演示应用程序是针对Java 11版构建的，但是可以对其进行调整以针对Java的其他版本。

• stages: The next section defines the stages of the build process. For a simple project I define three stages: compile, test, and package.

  stages ：下一部分定义了构建过程的阶段。 对于一个简单的项目，我定义了三个阶段：编译，测试和打包。

• before_script & cache: The before_script section defines commands that get run before each and every step. In this case I am setting the GRADLE_USER_HOME system variable to the correct path. This complements the following cache section to store the .gradle/ folder in the shared cache between steps. These steps are not necessary but they make the pipeline run a little faster.

  before_script & cache: before_script部分定义在每个步骤之前运行的命令。 在这种情况下，我将GRADLE_USER_HOME系统变量设置为正确的路径。 这是对以下cache部分的补充，以在步骤之间将.gradle/文件夹存储在共享缓存中。 这些步骤不是必需的，但它们会使管道运行得更快一些。

• compile: The compile section is the first actual build step. It belongs to the compile stage and its purpose is to compile the code and ensure there are no build errors. This step runs the gradle assemble command.

  compile ： compile部分是第一个实际的构建步骤。 它属于compile阶段，其目的是编译代码并确保没有构建错误。 此步骤运行gradle assemble命令。

• test: As the name suggests, the purpose of the test section is to run tests. This step runs the gradle test command to run all the tests. In this project, the tests were created using the JUnit5 framework.

  test ：顾名思义， test部分的目的是运行测试。 此步骤运行gradle test命令以运行所有测试。 在这个项目中，测试是使用JUnit5框架创建的。

• code_style: This section defines how to check the code for code-style errors. I use Ktlint for this because it is so easy to set up and use. Ktlint is configured in the build.gradle file and I made the following two tweaks to the default configuration.

  code_style ： 本节定义如何检查代码中的代码样式错误。 我Ktlint使用Ktlint是因为它很容易设置和使用。 在build.gradle文件中配置了Ktlin t，我对默认配置进行了以下两个调整。

• Generate an output file with the results at build/ktlint.xml

  生成一个输出文件，其结果位于build/ktlint.xml

• Allow wildcard imports. By default Ktlint will flag wildcard imports as an error. However, this clashes with the default behaviour of my IDE (IntelliJ), which will use wildcard imports where possible. This is a controversial topic but I chose to allow them. You can re-enable this rule by updating the build.gradle file and remove the flag for disabled rules the Ktlint settings: "--disabled_rules=no-wildcard-imports"

  允许通配符导入。 默认情况下， Ktlint将通配符导入标记为错误。 但是，这与我的IDE( IntelliJ )的默认行为发生冲突，该行为将在可能的情况下使用通配符导入。 这是一个有争议的话题，但是我选择允许他们。 您可以通过更新build.gradle文件并在Ktlint设置中删除禁用规则的标志来重新启用该规则： "--disabled_rules=no-wildcard-imports"

• package: This is the final step of the build. It’s part of the package stage and its purpose is to compile the project into a single “fat jar” and store it as an artifact for later use. This step uses the Shadow Jar Gradle plugin to generate the jar file. If it makes sense for your project, you can update this file to only run this step on certain branches (e.g. only on master) to avoid generating build artifacts for code that’s still in development.

  package ：这是构建的最后一步。 它是package阶段的一部分，其目的是将项目编译为单个“胖罐”，并将其存储为工件以供以后使用。 此步骤使用Shadow Jar Gradle插件生成jar文件。 如果对您的项目有意义，则可以更新此文件，使其仅在某些分支(例如，仅在主分支)上运行此步骤，以避免为仍在开发中的代码生成构建工件。

If you want to learn more about setting up build pipelines with this file you can read more in the documentation.

如果要了解有关使用此文件设置构建管道的更多信息，可以在文档中阅读更多内容 。

结论 (Conclusion)

In this article, I focused on building and testing Kotlin code, but Gitlab pipeline functionality is not limited to Kotlin or Gradle. There are plenty of other creative ways you can use pipelines for all kinds of languages.

在本文中，我专注于构建和测试Kotlin代码，但是Gitlab管道功能并不限于Kotlin或Gradle。 您还可以使用许多其他创造性的方式将管道用于各种语言。

I hope this helped you set up build automation for your own personal or professional projects. Or at least got you thinking about it.

我希望这可以帮助您为自己的个人或专业项目设置构建自动化。 或者至少让您考虑了一下。

If for some reason you’re dead-set on using Github instead, Gitlab even offers the option to run pipelines for external projects hosted on Github. Read more about that in the documentation.

如果由于某种原因您对使用Github感到束手无策，Gitlab甚至提供了为在Github上托管的外部项目运行管道的选项。 在文档中阅读有关此内容的更多信息。

Thank you for reading. What will you build?

感谢您的阅读。 你会建造什么？

资源资源 (Resources)

• Demo project

  示范项目

• Gitlab docs

  Gitlab文件

• Documentation on build pipelines

  有关构建管道的文档

• .gitlab-ci.yml reference

  .gitlab-ci.yml 参考

• Documentation on Gitlab static sites

  Gitlab静态站点上的文档

• Gitlab CI for Github projects

  适用于Github项目的Gitlab CI

• Ktlint

  克林特

• ShadowJar

  影剑