We are writing a project. Add SpringBoot and set up a CI process - "Java project from A to Z"

An article from a series about creating a Java project (links to other materials are at the end). Its goal is to analyze key technologies, the result is to write a telegram bot. Greetings, dear readers. As described in the previous part, we will go according to plan. We have already created a project and it’s time to fill it with code. Now all issues will be added as separate commits. I will describe everything that is necessary here. If I miss something or don’t describe it clearly enough, ask in the comments, I’ll try to answer.

We write JRTB-0M

In this task we need to add an empty SpringBoot framework for future work. We will do this in the same way as we did in the article about SpringBoot + Flyway . Download the project , open it in IDEA and create a new branch called JRTB-0 . I described how to do this through an idea here . This will make it easier for us to track work in the future. Did you already know that there is no longer a master branch? Now it is called neutrally - main . So we get used to it. Although, to be honest, we can always rename it back to master. We go to Spring Initializr and create a SpringBoot framework for our bot. At the moment, the youngest version of the boot sprint offered is 2.3.7, let's take it. I will describe the following settings separately:

• Project: Maven Project - we have already discussed Maven here and here . Therefore, I will additionally describe only what I did not disclose in previous articles. If there are such “white spots”, of course)
• Language: Java - everything is clear here. If there is a desire, we can rewrite this matter in Kotlin. I just bought myself a book Kotlin in Action, we’ll learn Kotlin together))
• Spring Boot: 2.3.7 - we take the smallest version offered to eliminate any problems. This is already a completely modern version of the boot.

Project Metadata:

• Group: com.github.javarushcommunity - here we select the domain on which our group of repositories is hosted.
• Artifact: javarush-telegrambot - maximum description of the project.
• Name: Javarush TelegramBot - we’ll write it in full here.
• Description: Telegram bot for Javarush from community to community - here is a more detailed description of the project.
• Package name: com.github.javarushcommunity.jrtb - here you can already use an abbreviation for the project name. Now the project will start with this package. Why so many? So that when we add other projects to the classpath, they will be in different packages. Each in their own unique way. This is important to maintain OOP principles.
• Packaging: Jar is our standard)
• Java: 11 - we'll be one step ahead. I don’t think that I will use innovations after the eighth Java, but let it be. He doesn’t ask for food)... this decision will give us a small Easter egg in the future)

We won’t add any dependencies for now. We don't need this for this task. Having filled in all this, we get (here is a link to the generated project): Having filled in, click GENERATE and add all the internals in the archive to our project. Add files to the project. As a result, we have an application. To check whether it is assembled at all, go to the terminal and write: $ mvn clean package If you have the same as from here, everything is ok: the project is assembled, and the jarnik is already ready in the target folder. At this point, the task within the description is ready. It's simple, right? Therefore, we commit and push to our branch: We add the name of our task at the beginning of the commit description, so that later it will be clear within the framework of which task the work was done. Click Commit and Push ... Once again we review and check what exactly we want to push from the local repository to the remote one and, making sure that everything is ok, click Push . What's our next step? According to all the rules (which can be read in this article , in the part about GitHub flow), you need to create a pull request for the main branch and wait for someone from the team to review the code. Since I'm on my own, I'll formally create a pull request and review everything again. I go to the repository page, and Github already knows that we have an addition and offers to create a pull request: There are no obstacles for patriots (c) - we create it, as suggested. We set the same label, project as on the task we are working on, and fill out the description: Click Create pull request .

Setting up the CI process

We go to the created pull request: below we see that we do not have Continuous Integration configured (hereinafter - CI). Well, it’s not configured, so what? Why do we need CI at all? What is CI anyway? This is approximately the list of questions that should concern us at this moment. In general, CI is a continuous process of merging code into a common code base and running a build of the project before that. The so-called build (from English build). Every time we build a project, we make sure that the project has been compiled, all its tests have passed successfully, plus after building the project, you can add autotests from testers to CI that are run on this specific build. This way, we become more confident that the new changes work as we expect and do not break the previous functionality. CI is also good because it starts automatically after updating the code base. That is, we pushed our changes into the branch and the process began - assembly, tests, autotests and other steps. If any of these steps fail, the build is considered broken and cannot be merged into the main branch. This is exactly what we will do now: we will add GitHub Actions, which will run our code after the push. GitHub Actions fits perfectly into our GitHub Flow, so we will use it to automate our work. This tool is very powerful and large, but for now we will only use it to run the build and check that it is assembled as needed. To enable it, find the Actions button on the repository page and follow it: Find the Continuous Integration workflow we need: Click Set up this workflow. Next, we are offered to use their template: we completely agree, let’s just clarify everything a little:

# 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

This indicates that GitHub Action is called in two cases:

1. When a push is made to the main branch.
2. When a pull request is created in the main branch.

The jobs section describes the steps that will be performed. We have only one step - build. It shows that our project will be launched in Ubuntu with the command mvn -B package --file pom.xml . This is exactly what we did locally. If you want to change something here, please. I will use this template, it will be enough for me. I click Start commit , select create a new branch to configure the process and then Propose new file . But the build process fell... As you can see, Failing after 14s - build. It looks like something happened: let’s move on to the assembly and look at the details: It says that I couldn’t find such a memory. Why? Ahhh, exactly, exactly! Because we created changes in the master branch, but our task is not there yet. And that’s why he didn’t find the memory... Therefore, now we do the following: we merge this data into the master, then we merge the main branch into JRTB-0, and then everything should go fine. In a pull request with github actions changes, click Merge pull request : And repeat Confirm merge . Next, Github prompts us to delete the branch in which we worked. We do not refuse and delete: Next, I did not find in the pull request from SpringBoot how to pull changes from the main branch from the website, so we will do it manually through IDEA.

Step 1: Update master branch to local repository.

The idea is to go to the master branch, press ctrl + t and update the master branch:

Step 2: Merge changes from the master branch to the JRTB-0 branch.

Let's go to JRTB-0 and merge the main one into it.

Step 3: push changes.

Press ctrl + shift + k and confirm the push. Now we are waiting for the build to pass and it will be green!)) But it is red again. What is it? We go into the actions logs and see that we have out of sync in the Java versions. In GitHubActions it is 8, but we use 11: Now there are two options: either correct the actions, or lower the version to the eighth. The first option, it seems to me, is better and more correct. We are making changes in a separate commit: we will work not with Java 8, but with Java 11. And after that, finally, everything worked out for us, and we were able to set up our CI process for the project. Such things need to be set up at the initial stage, so that you don’t have to worry about it later. Now you can see that the build has passed and you can merge without fear:

Setting up work with branches in the repository

You can also configure such things in the repository as rules when working with branches. I want to make it so that the main branch cannot be pushed directly, but only through pull requests, and I want to make it so that it is impossible to merge a pull request if the build fails (that is, if GitHub Actions failed at some step ). To do this, find the Settings button and select Branches : At the moment there are no rules for branches, so let’s add a new one through the Add rule button : There are a lot of settings here, and everyone can do something to suit their needs. In order for the build to pass successfully in the pull request before merging, add a checkbox to Require status checks to pass before merging and select the status we need - build. That's enough for now: then you can update this steering wheel and see what else you want. Click Create to create this steering wheel. Next, if we go to our pull request again, we can see that our check is now marked required: Let’s check our project page, which displays all task statuses: You can immediately see what task is being worked on. Moreover, the work has already been done, and the task is in code review status.

Closing JRTB-0

Now that we have prepared a pull request and made a CI for it, we need to complete the last stage: close the task, move it to the correct status, look at the changes in our project on the board. Our pull request is ready to be merged into the master. In the pull request, click the Merge pull request button : After a successful merge, you can delete it, and usually do so. I won't do this to make it easier for you to see changes between branches/commits. As soon as a pull request is merged, it automatically goes to done in our project board: The last step is to close the issue (issue) with a link to the pull request in which it was: This issue automatically goes to done on the board. The beginning has been made, the first task is done!

conclusions

It would seem that we have already started working and writing code, but settings are still needed. Yes, it takes time, but it will pay off a hundredfold when the project becomes larger and more complex and you need guarantees that you won’t just break everything with one commit. The pull request where this all happens is available here . Perhaps, when you read, it will already be closed. It's not scary: all the necessary information will be stored via the link. Thank you all for reading, see you soon. Further more!

A list of all materials in the series is at the beginning of this article.