我们正在写一个项目。添加 SpringBoot 并设置 CI 流程 - 《Java 项目从 A 到 Z》

有关创建 Java 项目的系列文章中的一篇文章（其他材料的链接位于最后）。其目标是分析关键技术，结果是编写一个电报机器人。 问候，亲爱的读者。正如前一部分所述，我们将按计划进行。我们已经创建了一个项目，是时候用代码填充它了。现在所有问题都将作为单独的提交添加。我将在这里描述所有必要的内容。如果我错过了什么或者描述得不够清楚，请在评论中提问，我会尽力回答。

我们写JRTB-0M

在这个任务中，我们需要添加一个空的 SpringBoot 框架以供将来的工作使用。我们将按照有关 SpringBoot + Flyway 的文章中的相同方式执行此操作。下载该项目，在 IDEA 中打开它并创建一个名为JRTB-0的新分支。我在这里描述了如何通过一个想法来做到这一点。这将使我们更容易跟踪未来的工作。您是否已经知道不再有主分支？现在它被称为中立主。所以我们就习惯了。不过，说实话，我们总是可以将其重命名回 master。我们转到Spring Initializr并为我们的机器人创建一个 SpringBoot 框架。目前，提供的 boot sprint 的最新版本是 2.3.7，我们就采用它吧。我将分别描述以下设置：

• 项目：Maven 项目- 我们已经在这里和这里讨论了 Maven 。因此，我将只额外描述我在之前的文章中没有透露的内容。当然，如果有这样的“白点”）
• 语言：Java - 这里一切都很清楚。如果有愿望，我们可以用 Kotlin 重写这件事。我刚刚给自己买了一本书《Kotlin in Action》，我们将一起学习 Kotlin））
• Spring Boot：2.3.7 - 我们采用提供的最小版本来消除任何问题。这已经是一款完全现代的靴子版本了。

项目元数据：

• 组：com.github.javarushcommunity - 在这里我们选择托管我们的存储库组的域。
• 工件：javarush-telegrambot - 项目的最大描述。
• 名称：Javarush TelegramBot - 我们将在这里完整地写下它。
• 描述：从社区到社区的 Javarush 电报机器人- 这是该项目的更详细描述。
• 包名称：com.github.javarushcommunity.jrtb - 在这里您已经可以使用项目名称的缩写。现在项目将从这个包开始。为什么这么多？这样当我们将其他项目添加到类路径时，它们将位于不同的包中。每个人都有自己独特的方式。这对于维护 OOP 原则非常重要。
• 包装：罐装是我们的标准）
• Java：11 - 我们将领先一步。我不认为我会在第八个 Java 之后使用创新，但就这样吧。他不要求食物）……这个决定将来会给我们一个小复活节彩蛋）

我们暂时不会添加任何依赖项。我们不需要这个来完成这项任务。填写完所有这些后，我们得到（这里是生成项目的链接）：填写完毕后，单击生成并将存档中的所有内部内容添加到我们的项目中。将文件添加到项目中。结果，我们有了一个应用程序。要检查它是否已组装，请转到终端并写入： $ mvn clean package如果与此处相同，则一切正常：项目已组装，并且 jarnik 已在目标文件夹中准备就绪。至此，描述中的任务已准备就绪。这很简单，对吧？因此，我们提交并推送到我们的分支：我们在提交描述的开头添加我们的任务名称，以便稍后可以清楚地知道工作是在哪个任务的框架内完成的。单击“提交并推送” ...我们再次检查并检查我们到底想要从本地存储库推送到远程存储库的内容，并确保一切正常，然后单击“推送”。我们的下一步是什么？根据所有规则（可以在本文有关 GitHub 流程的部分中阅读），您需要为主分支创建拉取请求，并等待团队中的某人审查代码。由于我独自一人，因此我将正式创建拉取请求并再次审查所有内容。我转到存储库页面，Github 已经知道我们有一个补充，并提供创建拉取请求：爱国者没有障碍 (c) - 我们按照建议创建它。我们设置与我们正在处理的任务相同的标签、项目，并填写描述：单击Create pull request。

设置 CI 流程

我们转到创建的拉取请求：下面我们看到我们没有配置持续集成（以下称为 CI）。嗯，还没配置，那又怎样？为什么我们需要 CI？CI到底是什么？这大约是我们目前应该关心的问题清单。一般来说，CI是一个将代码合并到公共代码库并在此之前运行项目构建的连续过程。所谓build（源自英文build）。每次构建项目时，我们都会确保项目已编译，所有测试均已成功通过，此外，构建项目后，您可以将测试人员的自动测试添加到在此特定构建上运行的 CI 中。这样，我们就更有信心新的更改会按我们的预期工作，并且不会破坏以前的功能。CI 也很好，因为它在更新代码库后自动启动。也就是说，我们将更改推送到分支中，然后流程开始 - 组装、测试、自动测试和其他步骤。如果这些步骤中的任何一个失败，则构建将被视为已损坏并且无法合并到主分支中。这正是我们现在要做的：我们将添加 GitHub Actions，它将在推送后运行我们的代码。GitHub Actions 非常适合我们的 GitHub Flow，因此我们将使用它来自动化我们的工作。该工具非常强大且庞大，但目前我们仅使用它来运行构建并检查它是否已根据需要进行组装。要启用它，请在存储库页面上找到“操作”按钮并按照它操作：找到我们需要的持续集成工作流程：单击“设置此工作流程”。接下来，我们被要求使用他们的模板：我们完全同意，让我们稍微澄清一下一切：

# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven

name: Java CI with Maven

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build with Maven
      run: mvn -B package --file pom.xml

这表明 GitHub Action 在两种情况下被调用：

1. 当推送到主分支时。
2. 当在主分支中创建拉取请求时。

作业部分描述了将执行的步骤。我们只有一步——构建。它表明我们的项目将使用命令mvn -B package --file pom.xml在 Ubuntu 中启动。这正是我们在当地所做的。如果你想在这里改变一些东西，请。我将使用这个模板，这对我来说就足够了。我单击“开始提交”，选择“创建新分支”来配置流程，然后选择“提议新文件”。但是构建过程失败了...如您所见，14 秒后失败 - 构建。看来发生了什么事：我们去大会看看细节：它说我找不到这样的内存。为什么？啊啊啊，正是，正是！因为我们在 master 分支中创建了更改，但我们的任务尚未完成。这就是为什么他没有找到内存......因此，现在我们执行以下操作：我们将这些数据合并到主分支中，然后将主分支合并到JRTB-0中，然后一切都会顺利。在 github 操作发生更改的拉取请求中，单击合并拉取请求:并重复确认合并。接下来，Github 提示我们删除我们工作的分支。我们不拒绝和删除：接下来，我在SpringBoot的pull request中没有找到如何从网站上pull主分支的更改，所以我们将通过IDEA手动完成。

步骤1：将master分支更新到本地存储库。

这个想法是转到 master 分支，按 ctrl + t 并更新 master 分支：

步骤 2：将 master 分支的更改合并到 JRTB-0 分支。

让我们转到 JRTB-0 并将主要部分合并到其中。

第 3 步：推送更改。

按 ctrl + shift + k 并确认推送。现在我们正在等待构建通过，它会变成绿色！））但它又变成红色了。它是什么？我们查看操作日志，发现 Java 版本不同步。在 GitHubActions 中它是 8，但我们使用 11：现在有两个选择：要么更正操作，要么将版本降低到第八个。在我看来，第一个选项更好、更正确。我们正在单独的提交中进行更改：我们将不使用 Java 8，而是使用 Java 11。最后，一切顺利，我们能够为该项目设置 CI 流程。这样的东西需要在初期就设置好，这样以后就不用担心了。现在您可以看到构建已经通过，您可以放心地合并：

设置存储库中分支的工作

您还可以在存储库中配置此类内容作为使用分支时的规则。我想让主分支不能直接推送，而只能通过拉取请求，并且我想让它在构建失败时无法合并拉取请求（即，如果 GitHub Actions 在某个步骤）。为此，找到设置按钮并选择分支：目前分支没有规则，所以让我们通过添加规则按钮添加新的规则：这里有很多设置，每个人都可以做一些适合自己的事情。需要。为了使构建能够在合并之前的拉取请求中成功通过，请添加一个复选框以在合并之前需要通过状态检查，并选择我们需要的状态 - 构建。现在就足够了：然后你可以更新这个方向盘，看看你还想要什么。单击“创建”以创建此方向盘。接下来，如果我们再次转到拉取请求，我们可以看到我们的检查现在被标记为必需：让我们检查我们的项目页面，该页面显示所有任务状态：您可以立即看到正在处理什么任务。而且，工作已经完成，任务处于代码审查状态。

关闭 JRTB-0

现在我们已经准备好了 Pull Request 并为其创建了 CI，我们需要完成最后一个阶段：关闭任务，将其移动到正确的状态，在看板上查看我们项目的变化。我们的拉取请求已准备好合并到主控中。在拉取请求中，单击合并拉取请求按钮：合并成功后，您可以将其删除，通常会这样做。我这样做并不是为了让您更容易地看到分支/提交之间的更改。一旦拉取请求被合并，它就会自动在我们的项目板中完成：最后一步是通过指向拉取请求所在的链接来关闭问题（问题）：此问题会自动在木板。开始已经开始，第一个任务已经完成！

结论

看起来我们已经开始工作并编写代码了，但是仍然需要设置。是的，这需要时间，但是当项目变得更大、更复杂并且您需要保证不会因为一次提交而破坏所有内容时，它会带来百倍的回报。发生这一切的拉取请求可以在这里找到。或许，当你阅读时，它已经关闭了。这并不可怕：所有必要的信息都将通过链接存储。感谢大家的阅读，很快再见。此外！

该系列所有材料的列表位于本文开头。